Código Primero vs. Base de Datos Primero

Cuando diseño y creo el software en el que trabajo, normalmente primero diseño y creo las tablas SQL de fondo y luego paso a la programación real. Sin embargo, el proyecto en el que estoy trabajando me tiene perplejo. Esto probablemente se deba a la falta de requisitos buenos y sólidos, pero lamentablemente hay poco que pueda hacer al respecto esta vez. Es un tipo de situación de "solo ve y haz que suceda" ... pero estoy divagando.

Estoy pensando en darle la vuelta a mi flujo de trabajo y crear primero las clases de IU y modelo de datos con la esperanza de que resolverlo me aclare cómo se verá mi esquema de base de datos. ¿Es esta una buena idea? Estoy nervioso de que termine con una interfaz de usuario y todavía no tengo idea de cómo estructurar la base de datos.

Si alguien tiene curiosidad, estoy usando SQL Server como back-end y MS Access como una aplicación front-end. (El acceso tampoco es mi elección ... así que no lo odies demasiado).

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

Por ejemplo, puede construir su modelo de datos de forma incremental implementando un solo caso de uso a la vez con solo persistencia en la memoria (o algo tan fácil de implementar). Cuando sienta que ha implementado suficientes casos de uso para delinear las entidades básicas, puede reemplazar la persistencia en 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 elimina el foco de la base de datos y la traslada al núcleo del problema: las reglas de negocio. Si comienza implementando las reglas de negocio, eventualmente encontrará (por un proceso muy similar a Natural Selection, por cierto) qué datos son realmente necesarios para el negocio. Si comienza modelando la base de datos, sin la retroalimentación 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 pesados ​​de migración, si la empresa ya se está ejecutando con él), o tendrá que implementar "soluciones" en las reglas de la empresa para compensar el modelo de datos desafinado.

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á qué datos necesita. Primero modele los datos, y es posible que pueda contar cuántos supuestos estaban equivocados cuando los 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", desarrollo basado en pruebas y un enfoque en desacoplar su arquitectura de los detalles que interponerse en su camino (pista: base de datos). Sobre el último, esta charla resume la idea bastante bien.

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

Hágase un favor y haga un análisis básico de los sistemas: identifique a algunos usuarios en varios niveles, haga un cuestionario rápido y sucio, apague la máquina, tome café y galletas / rosquillas (o lo que sea que engrase las ruedas) y luego camine hasta sus escritorios, pregúnteles qué hacen y qué necesitan saber / grabar 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 un arreglo para regresar en otro momento o déjelo con ellos.

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

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. Esos datos le darán pistas sobre las tablas que necesita para guardarlos.
• Muchas veces ya se está utilizando un proceso, pero de forma manual o utilizando varias herramientas dispares que no están automatizadas, no interactúan y / o no se ajustan a los estándares.
• Una vez que tenga un modelo de base de datos semi-maduro, puede comenzar a diseñar formularios prototipos, ventanas, etc., que lean y escriban en esa base de datos.
• A medida que continúe, serán necesarios algunos cambios para acomodar las cosas que no se contemplan al principio.

También recuerda:

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

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

Iba a decir Base de datos primero porque tengo mucha experiencia con grandes proyectos 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 grandes proyectos más exitosos era "requisitos primero".

Un buen conjunto de requisitos empresariales bien especificados 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.

Dado que esto parece tan fluido / no especificado, primero haría la interfaz gráfica de usuario de la interfaz; eso parece lo que necesita para obtener respuestas, apoyo, tiempo y comentarios de las partes interesadas, ¿verdad? No les importan las tablas brillantes normalizadas y las restricciones de claves externas y las eliminaciones en cascada. Pero una GUI genial con muchos colores brillantes, bueno, ¡eso es de primera categoría!

Para la "base de datos" de 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 ligero". (¿una tabla de hojas de cálculo?) Sea lo que sea rápido y sucio, planea tirarlo a la basura.

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

Ahora, tal vez sus partes interesadas son expertos en bases de datos, ¡ese ha sido el caso conmigo a veces! - en cuyo caso, haga algunos diseños de DB.

Dado que los requisitos no están claros, uno 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, serializar a binario o XML y almacenar el BLOB en la base de datos para empezar. Eso debería permitirle a uno desarrollar la IU y la capa empresarial (nivel medio) sin un modelo totalmente relacional, pero aún tendrá persistencia para guardar y recuperar y búsquedas de claves simples según sea necesario.

Como ejemplo, tal vez tenga una Persona, por lo que tiene un PK de Id. De persona. El resto de los atributos no se conocen, así que simplemente comience con una tabla 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 que el modelo sea relacional. Entonces es solo 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 negocios, la interfaz de usuario, etc., seguirán funcionando. 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 retrasarse ya que no puede consultar un BLOB, por lo que a medida que el modelo se estabilice, comience a almacenar sus datos que deben buscarse en columnas relacionales.

Básicamente, comienza con un modelo tabular y pasa a uno relacional a medida que avanza el proyecto.

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

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

Si los requisitos no están claros, puede crear un modelo de datos de su interpretación de los requisitos. Tal vez lo mejor sea escribir algunos requisitos y enviárselos a su empleador, para que tengan algo a lo que disparar. O cree primero una interfaz gráfica de usuario, depende del tipo de empleador que funcione mejor :)