Código Primero vs. Base de Datos Primero

77

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).

RubberDuck
fuente
66
@gnat: Eso es completamente diferente.
Robert Harvey
1
Si esto se cierra como un duplicado, debería ser un duplicado de esta pregunta . Las respuestas y la pregunta están más en línea con lo que estoy preguntando.
RubberDuck
1
@Mawg es un proyecto de trabajo. He retrocedido todo lo que he podido para lograr que los requisitos se concreten. El trabajo tiene que comenzar en esto y no hay nada más que pueda hacer al respecto.
RubberDuck
44
Errrm, ¿nuevo trabajo? Sé que lo haría. Pero como freelance de 30 años, me resulta fácil alejarme antes de que realmente golpee al fanático (algunas personas simplemente no pueden ayudar), pero me doy cuenta de que no es tan fácil para todos. Quédese si debe hacerlo (no hay un empleador comparable en la zona, etc.), pero no te quedes si te empieza a afectar.
Mawg

Respuestas:

85

¿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.

MichelHenrich
fuente
1
"La base de datos es un detalle". Muchas gracias por el enlace. Creo sinceramente que podré abordar este proyecto dejando la base de datos como una decisión diferida después de ver esa charla.
RubberDuck
66
Y solo para ponerle un nombre: estas prácticas son todas (posiblemente las ) prácticas importantes en el desarrollo ágil (desarrollo incremental, lo más simple que podría funcionar, basado en pruebas, las necesidades del usuario primero ...).
sleske
8
Quería volver y agradecerle nuevamente. Tengo todo mi nivel medio trabajando sin una base de datos y ahora tengo una gran comprensión de cómo deben persistir los datos. No puedo agradecerte lo suficiente. Votaría de nuevo si pudiera.
RubberDuck
12
Si realmente captura todos los requisitos a través de su método de código primero, y realmente expresa todos esos requisitos en su base de datos final , puedo estar de acuerdo con esta respuesta. Pero he visto muchos, muchos proyectos donde la satisfacción de hacer que algo "funcione" da como resultado la actitud de que "si está funcionando, la base de datos debe ser lo suficientemente buena", incluso cuando se trata de un diseño HORRIBLE de base de datos, con problemas de rendimiento graves e inevitables. más tarde. Además, muchas personas parecen pensar que si el código está validando datos, no necesita restricciones CHECK o FOREIGN KEY. Lo haces .
Ross Presser
2
Posiblemente esto esté cubierto en el video, desafortunadamente no puedo llegar a eso en este momento, pero otra ventaja del enfoque incremental es que cuando se hace correctamente ayuda a solidificar las especificaciones vagas. "¿Parece que esta pantalla está capturando toda la información de contacto que necesita? ¿Están los campos ordenados en un orden que tenga sentido con su flujo de trabajo?" Poder hacer estas preguntas, con algo concreto como referencia, es el IME con frecuencia la única forma de obtener la información que necesita.
David
17

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.

James Snell
fuente
Estoy totalmente de acuerdo, pero eso no va a suceder en este caso. Gracias por tu tiempo sin embargo.
RubberDuck
99
Si no tiene tiempo para hacerlo bien, ¿dónde encontrará tiempo para hacerlo nuevamente?
Walter Mitty
¿Quién dijo algo sobre no hacerlo bien @WalterMitty? Por favor vea el enlace del video en la respuesta aceptada. La base de datos es un detalle que no necesita estar en su lugar para solucionar los problemas del 95% del software.
RubberDuck
1
Supuse que "eso no va a suceder" significa que va a proceder al código sin siquiera tener una idea de qué información necesitan las partes interesadas del sistema. Creo que James le dio muy buenos consejos sobre cómo hacer análisis de sistemas básicos sin verse atrapado en la parálisis del análisis.
Walter Mitty
Me entendiste mal @WalterMitty. He adoptado un enfoque de retroalimentación. Construiré lo que creo que debería (sin una base de datos) y luego lo llevaré a los usuarios. Modificar el programa Repetir. Después de algunas iteraciones de eso, debería saber exactamente cómo se verá la base de datos. Según tengo entendido, el enfoque ágil está específicamente diseñado para hacer frente a requisitos poco claros. Se ve en mí bien en este proyecto.
RubberDuck
12

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.

Tulains Córdova
fuente
Esas son todas cosas muy verdaderas, y de hecho esto será lo que sustituya un "no-proceso" y hoja de cálculo, pero no veo cómo esto es una respuesta a mi pregunta. ¿Puedes por favor aclarar?
RubberDuck
1
@RubberDuck Agregué una aclaración al final de mi respuesta.
Tulains Córdova
11

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.

James Anderson
fuente
Así es exactamente como trabajo típicamente. Requisitos primero , sí. Cómo me gustaría poder sacar algunos requisitos sólidos de alguien en este momento.
RubberDuck
Requisitos primero, aunque no debe esperar hasta que los requisitos estén completos (nunca lo están). Comience una vez que tenga suficiente para tener una idea de cuáles son los objetivos de la aplicación, luego obtenga más cuando los necesite.
sleske
@sleske: un buen analista debería tener una idea de las partes más "dinámicas" (es decir, vagas y cambiantes) de los requisitos y crear cierta flexibilidad en el diseño para hacer frente fácilmente a los caprichos de los usuarios.
James Anderson
1
@JamesAnderson: En realidad, soy un gran admirador de los principios de desarrollo ágil, donde generalmente solo diseñas para lo que necesitas ahora , a menos que sepas que no puedes cambiar el diseño más tarde (rara vez es el caso). Pero estoy empezando a salir del tema ...
sleske 03 de
8

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.

user949300
fuente
3
+1 para "código primero" ni "base de datos primero" sino "prototipo gui no funcional primero" (también conocido como "creación rápida de prototipos"), porque en ausencia de requisitos, el prototipo gui ayuda a aclarar los requisitos con los usuarios finales.
k3b
1
Es cierto, pero también les hace creer que la aplicación es tan buena como terminada. Me quemé de esa manera antes y ahora exijo que primero tengamos los requisitos
correctos
@Mawg sí, desafortunadamente eso es un peligro. Una opción (al menos en Java) es usar un "look and feel" extraño para dejar en claro que este es un prototipo.
user949300
Si no sabe a dónde va, cualquier código lo llevará allí.
-1

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.

Jon Raynor
fuente
De esta manera yace la locura. Nunca conserve los datos hasta que esté listo para conservarlos. Normalizar los datos después del hecho es una pesadilla.
RubberDuck
1
Hay una diferencia entre persistencia y normalización. La pregunta que solo usted puede responder es si necesito persistir solo, o persistir y normalizar. Un modelo de datos es un modelo, si no hay requisitos, entonces es difícil modelar algo relacionalmente.
Jon Raynor
-2

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 :)

Kein IhpleD
fuente
3
Esto no parece ofrecer nada sustancial sobre los puntos hechos y explicados en las 5 respuestas anteriores
mosquito
Mi punto es seguir el enfoque dependiendo del tipo de cliente
Kein IhpleD