Código primero contra base de datos primero

¿Qué fue primero, el proceso o los datos utilizados por ese proceso? Sé que esta es una pregunta tipo "el huevo o la gallina", pero en el caso del software, creo que es el proceso.

Por ejemplo, puede construir su modelo de datos de manera incremental implementando un solo caso de uso a la vez con solo la persistencia en la memoria (o cualquier cosa tan fácil de implementar). Cuando crea que ha implementado suficientes casos de uso para describir las entidades básicas, puede reemplazar la persistencia en la memoria por una base de datos real y luego continuar refinando el esquema a medida que avanza, un caso de uso a la vez.

Esto quita la atención de la base de datos y la traslada al núcleo del problema: las reglas comerciales. Si comienza implementando las reglas de negocios, eventualmente encontrará (por cierto, un proceso muy similar a la Selección Natural) qué datos son realmente necesarios para el negocio. Si comienza por modelar la base de datos, sin la respuesta de si esos datos son realmente necesarios (o en ese formato, o en ese nivel de normalización, etc.), terminará haciendo muchos ajustes tardíos en el esquema (que puede requerir procedimientos de migración pesados, si el negocio ya se está ejecutando con él), o tendrá que implementar "soluciones alternas" en las reglas de negocios para compensar el modelo de datos fuera de sintonía.

TL; DR: La base de datos depende de la empresa, está definida por ellos. No necesitará los datos a menos que tenga un proceso que funcione con ellos (un informe también es un proceso). Primero implemente el proceso y encontrará los datos que necesita. Modele los datos primero, y es posible que pueda contar cuántas suposiciones fueron incorrectas cuando lo modeló por primera vez.

Un poco fuera del tema, pero muy importante: el flujo de trabajo que describo a menudo se usa junto con prácticas muy importantes como "Lo más simple que podría funcionar", el desarrollo guiado por pruebas y un enfoque para desacoplar su arquitectura de Los detalles que se interponen en tu camino (pista: base de datos). Acerca del último, esta charla resume la idea bastante bien.

Un análisis de causa raíz sugiere que este problema no es de método, sino que es la falta de una especificación. Sin uno, realmente no importa lo que escribas primero, de todos modos lo vas a tirar.

Hágase un favor y haga un análisis básico de los sistemas: identifique algunos usuarios en varios niveles, invente rápidamente & El cuestionario sucio luego apaga su máquina, toma un poco de café y galletas / donas (o lo que sea que engrasa las ruedas), luego camine hasta sus escritorios, pregúnteles qué hacen y qué necesitan saber / registrar para hacer su trabajo, incluso si Parece obvio - todavía pregunte. No se preocupe por lo importantes que son, si están demasiado ocupados, haga arreglos para regresar en otro momento o déjelos en su lugar.

Una vez que tengas eso, deberías poder comenzar a construir lo que crees que te dará los mejores resultados y esperar a que llegue el resto de la especificación.

Iba a decir Base de datos primero, ya que tengo mucha experiencia con proyectos grandes y realmente necesitas un modelo de datos sólido si tienes muchos desarrolladores trabajando en paralelo.

Pero luego lo pensé un poco más y me di cuenta de que lo que realmente estábamos haciendo en los proyectos grandes más exitosos era "los requisitos primero".

Un buen conjunto bien especificado de requisitos empresariales, conduce a un buen conjunto de requisitos funcionales. Si tiene un buen conjunto de requisitos funcionales, entonces el modelo de datos y las especificaciones del módulo simplemente encajan sin mucho esfuerzo.

Mi experiencia es la siguiente:

• En la mayoría de los proyectos en los que he trabajado, primero diseñamos la base de datos.
• Muchas veces los datos ya existen en hojas de cálculo, bases de datos heredadas, papel, etc. Estos datos te darán sugerencias sobre las tablas que necesitas para guardarlas.
• Muchas veces ya se está utilizando un proceso, pero manualmente o usando varias herramientas dispares que no están automatizadas, no interactúan y / o no cumplen con los estándares.
• Una vez que tenga un modelo de base de datos semi-maduro, puede comenzar a diseñar formularios prototipo, ventanas, etc., que lean y escriban en esa base de datos.
• A medida que continúe, serán necesarios algunos cambios para adaptarse a las cosas que no se contemplan al principio.

También recuerda:

• Ya no es un mundo de una sola aplicación < - > one-database. Tal vez su aplicación tendrá que leer o escribir datos de más de una base de datos o su solución incluirá más de una aplicación utilizando la misma base de datos.

Conclusión: te recomiendo que primero diseñes la base de datos.

Ya que esto parece tan fluido / no especificado, yo haría primero la interfaz gráfica de usuario (GUI) inicial, lo que parece ser lo que necesita para obtener respuestas, apoyo, tiempo y comentarios de los interesados, ¿no? No les importan sus brillantes tablas normalizadas y las restricciones de las claves externas y las eliminaciones en cascada. Pero una GUI genial con muchos colores brillantes, bueno, ¡eso es de primera!

Para la "base de datos" del backend inicial, use algo extremadamente simple, tal vez solo claves / valores almacenados en un archivo. No estoy familiarizado con MS Access, así que no sé cuál sería el backend "más liviano". (¿Una tabla de hoja de cálculo?) Lo que sea rápido y sucio, planea tirarlo.

Si puede, use un aspecto divertido en la GUI para dejar claro que es un prototipo. Si todo lo demás falla, usa tarjetas de índice.

Ahora, tal vez sus partes interesadas sean expertos en DB. ¡Ese ha sido el caso conmigo a veces! - En ese caso, haz algunos diseños de DB.

Dado que los requisitos no están claros, se puede comenzar con un modelo de datos muy rudimentario con los elementos clave que sabrá que necesita, tal vez solo tablas básicas y PK para comenzar. El resto de los datos, serialice a binario o XML y almacene el BLOB en la base de datos para comenzar. Eso debería permitirle a uno desarrollar la UI y la capa de negocios (nivel medio) sin un modelo completamente relacional, pero aún tendrá persistencia para guardar y recuperar y realizar búsquedas de claves simples según sea necesario.

Como ejemplo, quizás tenga una Persona, así que tiene un PK de Identificación de Persona. El resto de los atributos no se conocen, así que simplemente comience con una tabla de Persona con un ID de Persona PK y otra columna que almacenará el Blob, todos los datos de la persona.

Una vez que los requisitos se solidifiquen tome sus Blobs y extraiga todas las tablas y columnas necesarias y haga el modelo relacional. Entonces solo es cuestión de cambiar la persistencia de un BLOB a relacional en la capa de acceso a datos. Pero todo lo demás, las reglas de negocio de la interfaz de usuario, etc. todavía funcionarán. Tenga en cuenta que esto agrega algo de tiempo al proyecto, pero permite una flexibilidad completa para agregar y soltar cosas según sea necesario sin cambiar el modelo relacional hasta que las cosas se vuelvan más firmes

la búsqueda puede demorarse ya que no puede consultar un BLOB, por lo que, a medida que el modelo se estabilice, comience a almacenar los datos que necesita buscar en las columnas relacionales.

Básicamente, comienzas con un modelo tabular y te mueves a uno relacional a medida que avanza el proyecto.

O, firme los requisitos antes de comenzar cualquier trabajo para que pueda desarrollarse inicialmente un modelo relacional.

En general, creo que el código viene después de los datos porque el código va a manipularlos.

Si los requisitos no están claros, puede crear un modelo de datos de su interpretación de los requisitos. Lo mejor es tal vez anotar algunos requisitos y enviarlo a su empleador, luego tienen algo para disparar. O cree una interfaz gráfica de usuario primero, depende del tipo de empleador que funcione mejor :)