¿Debería diseñar la base de datos antes de escribir el código de la aplicación?

¿Cuál es la forma más fácil y eficiente de diseñar una base de datos? Desde mi perspectiva, hay un par de opciones para el diseño del almacén de datos de una aplicación:

1. Diseñe la base de datos lo mejor que pueda inicialmente antes de escribir cualquier código de aplicación . Esto le brinda la ventaja de tener una estructura de datos base para trabajar. La desventaja de esto, en mi opinión, es que tendrá muchos cambios como especificaciones de la aplicación que afectan el qué / dónde / cómo cambian los datos a lo largo del ciclo de desarrollo de la aplicación.
2. Diseñe la base de datos a medida que la aplicación llegue a buen puerto . Cuando necesita algunos objetos de la base de datos mientras escribe la aplicación, desarrolla la base de datos paralela (cronológicamente) a la aplicación. Las ventajas serían menos cambios en la estructura de la base de datos tal como la veo. La desventaja sería la división del tiempo y el esfuerzo de desarrollo entre el código de la aplicación y el desarrollo de la base de datos.

En su experiencia, ¿cuál considera que es el método más productivo y eficiente?

Además de otras respuestas ...

Capturar su modelo conceptual primero debe definir el alcance y los requisitos. De esto, puede derivar sus modelos de datos lógicos y físicos.

Una vez que esto es mayormente estático, entonces tiene una base de datos estable para construir su aplicación. Esto es contrario a su primera opción.

Su segundo punto terminará en una bola de barro desordenada e imposible de mantener . El modelo de datos nunca será reparado: si no lo diseñó por adelantado, no tendrá tiempo para arreglarlo antes del envío. Estarán demasiado ocupados pirateando cosas juntos.

Se producirán cambios menores en el esquema, combinando o dividiendo tablas, cambiando relaciones, etc., pero en las "islas" localizadas, su modelo + diseño básico no se modificará.

Será difícil encontrar un departamento de software moderno que no esté operando alguna variante de Agile. Los DBA en comparación están atrapados en la edad oscura, con el tipo de pensamiento de que la respuesta de @ RobPaller todavía tiene un lugar común.

Modificar un esquema de base de datos nunca ha sido tan fácil como modificar código, por lo que ha habido renuencia a adoptar un enfoque ágil para el desarrollo y mantenimiento de bases de datos. Ahora que tenemos las herramientas y técnicas para operar de manera similar a los desarrolladores, definitivamente deberíamos hacerlo. El hecho de que no sea fácil cambiar el esquema no significa que no puedas y que no debas.

No estoy abogando por un enfoque casual para el diseño de bases de datos (ver comentarios), simplemente un enfoque que refleja más de cerca el de un equipo de desarrollo ágil. Si forma parte de un proyecto ágil, no tendrá requisitos de trabajo que puedan ( o no ) ocurrir en el futuro, por lo que debe diseñar lo que sabe, no lo que podría ser.

¡Supongo que eso pone mi voto con su opción 2 y sospecho que podría encontrarme parado en este caso!

Su modelo de datos lógico debe capturar efectivamente los requisitos comerciales de su aplicación. El diseño de su base de datos física debe basarse en el modelo de datos lógicos combinado con los cambios necesarios que usted, como DBA, necesita para maximizar la eficiencia de su RDBMS.

Si descubre que tiene que hacer numerosos cambios en el diseño de la base de datos subyacente a lo largo del ciclo de vida de desarrollo de software de su aplicación, es indicativo de dos cosas:

1. Desplazamiento del alcance : permite que se introduzcan nuevos requisitos en un momento inapropiado.
2. Requisitos empresariales insuficientes : sus modeladores de datos (o analistas de sistemas) no tradujeron suficientemente los requisitos de los analistas comerciales. Esto dio como resultado un modelo de datos incompleto o incorrecto para admitir los requisitos de su aplicación.

Dicho esto, una vez que una aplicación se ha entregado a producción, no es raro tener que regresar y realizar cambios iterativos en el modelo de datos para respaldar la evolución natural de la aplicación o los procesos comerciales subyacentes.

Espero que esto ayude.

Me he dado el lujo de diseñar varias bases de datos de complejidad media, todas utilizadas en empresas, con varios front-end que incluyen web, Access y C #.

Por lo general, me he sentado y elaboré el esquema de la base de datos de antemano. Esto siempre tuvo más sentido para mí. Sin embargo, no ha habido un solo caso en el que no termine haciendo cambios, agregando nuevas tablas o viviendo con aspectos que me molestaron y que básicamente fueron demasiado tarde para solucionarlos.

No creo que la cura sea escribir el código primero. Y no creo que el problema sea "requisitos comerciales insuficientes" o, al menos, no uno que podría haberse resuelto por completo. Los usuarios no saben lo que necesitan y no tengo el poder para hacerlos pensar más o ser más inteligentes o más conscientes o responder mejor a mis preguntas. O discuten y me ordenan hacer algo de cierta manera.

Los sistemas que construyo generalmente están en áreas nuevas en las que nadie ha entrado antes. No tengo el compromiso de la organización, los recursos o las herramientas para hacer el tipo de trabajo que podría hacer un equipo de desarrollo de profesionales de diseño de primer nivel a quienes se les pagó como equipo diez veces más de lo que hago para construir cosas dos veces el tiempo

Soy bueno en lo que hago. Pero solo uno de mí lo hace en un entorno que "no hace desarrollo".

Dicho todo esto, estoy mejorando para descubrir las reglas de negocios. Y veo una especie de tercera opción:

Antes de diseñar la base de datos, y antes de escribir cualquier código, dibuje pantallas crudas que muestren cómo funcionará la aplicación. Deben estar dibujados a mano para evitar que alguien comente sobre la fuente, el tamaño o las dimensiones; solo desea la función.

Con transparencias y trozos de papel, puede intercambiarlos, hacer que una persona sea la computadora, dos sean usuarios no técnicos expertos en la materia (dos para que hablen en voz alta) y una persona allí como facilitador que toma notas y dibuja los usuarios sobre sus procesos de pensamiento y confusiones. Los usuarios "hacen clic" y arrastran y escriben en cuadros, la "computadora" actualiza la pantalla y todos pueden experimentar el diseño. Aprenderá cosas que de otro modo no podría haber aprendido hasta muy avanzado el proceso de desarrollo.

Tal vez me estoy contradiciendo a mí mismo, tal vez sea un mejor descubrimiento de requisitos. Pero la idea es diseñar la aplicación primero, sin escribir ningún código. ¡He comenzado a hacer esto a pequeña escala, y está funcionando! A pesar de los problemas en mi entorno, me está ayudando a diseñar mejor la base de datos desde el principio. Aprendo que una columna debe moverse a una nueva tabla principal porque hay varios tipos. Aprendo que la lista de trabajo debe tener órdenes permanentes que no provienen del sistema de órdenes integrado. ¡Aprendo todo tipo de cosas!

En mi opinión, esta es una gran victoria.

Para la mayoría de los propósitos, elegiría la Opción 2: Construir la base de datos en paralelo con los otros componentes. Siempre que sea posible, adopte un enfoque iterativo y brinde funcionalidad de extremo a extremo a medida que construye cada pieza.

Esto requiere una cierta cantidad de disciplina del proyecto. Aplique la normalización rigurosamente (Boyce-Codd / Fifth Normal Form) cada vez que cambie la base de datos para mantener la calidad y no terminar con un modelo ad-hoc e inconsistente. Sea lo más agresivo posible con las reglas comerciales y las restricciones de la base de datos correspondiente. En caso de duda, es mejor hacer cumplir una restricción antes de tiempo; siempre puede eliminarla más tarde. Sea inteligente sobre el orden en que implementa los componentes arquitectónicos para minimizar la deuda técnica. Tenga un buen conjunto de pautas de diseño de bases de datos que todo el equipo de desarrollo acepte.

Todo esto, por supuesto, debe ir de la mano con otras buenas prácticas de ingeniería de desarrollo: integración continua, automatización de pruebas y, fundamentalmente, desde la perspectiva de la base de datos, crear datos de prueba. La creación de datos de prueba de datos de tamaño realista debe hacerse en cada iteración sin falta.

En el mundo de la arquitectura, la frase "La forma sigue a la función" se acuñó y luego se adhirió al construir edificios altos. Lo mismo debe aplicarse a la infraestructura de bases de datos y al desarrollo de aplicaciones.

Imagine escribir una aplicación y decidir sobre la marcha que necesita una mesa aquí y una mesa allí. Cuando finaliza su aplicación, tiene una gran cantidad de tablas que se tratan como matrices. Mirando todas las tablas una al lado de la otra, las tablas definitivamente parecerán no tener rima o razón.

Desafortunadamente, algunas tiendas de desarrolladores recogerán algo como memcached, lo cargarán con datos en RAM (tratándolo así como un conducto de datos) y tendrán una base de datos, como MySQL o PostgreSQL, que se comportará simplemente como una unidad de almacenamiento de datos.

El incentivo para usar una base de datos debe ser mirarla correctamente: como un RDBMS. Sí, un sistema de gestión de bases de datos relacionales . Cuando utiliza un RDBMS, su objetivo inicial no solo debe ser establecer tablas para el almacenamiento, sino también para la recuperación. Las relaciones entre tablas deben modelarse según los datos que desea ver y cómo se presentan. Esto debe basarse en la coherencia e integridad de los datos junto con las reglas comerciales conocidas. Esas reglas comerciales pueden codificarse en su aplicación (Perl, Python, Ruby, Java, etc.) o en la base de datos .

CONCLUSIÓN

Definitivamente iría con la opción 1. Se necesita una planificación adecuada, modelado de datos y análisis continuo de datos. Sin embargo, esto debería minimizar los cambios en la base de datos a largo plazo.

Creo que debe hacerse antes de que haya algún código real para la aplicación, pero no antes de que la aplicación esté diseñada.

Mi flujo de trabajo típico, si trabajo solo es:

1. Determinar qué debe hacer la aplicación
2. Observe si alguna de las tareas puede desglosarse para componentes reutilizables.
3. Determine cómo cada tarea debe interactuar con el almacenamiento de datos: qué tipo de preguntas harán a los datos, con qué frecuencia escribirán, etc.
4. Diseñe la base de datos de modo que pueda responder a todas las preguntas que necesitemos y que funcione bien para las tareas más frecuentes.
5. Escribe la solicitud.

Como trabajo con frecuencia como parte de un equipo, y estamos dispersos geográficamente (y en zonas horarias), tendemos a tener una reunión inicial inicial:

1. Determine qué debe hacer la aplicación.
2. Determine dónde están los puntos buenos para dividir la aplicación en componentes independientes
3. Determine cómo cada componente necesitará interactuar con los demás.
4. Acuerde una API para cada una de las interacciones.

Luego, volvemos a casa, escribimos nuestra parte, y si un componente necesita su propio almacenamiento local, siempre y cuando el responsable de esa parte mantenga la API en su módulo consistente. El almacenamiento de datos principal se maneja como un módulo con su propia API, y se espera que las personas escriban en él. (en casos donde la velocidad de la base de datos es crítica, la API son las definiciones de la tabla, y si se realizan cambios, usamos vistas u otro mecanismo para presentar la versión anterior hasta que todos los módulos puedan actualizarse)

Tengo en mente la siguiente regla: "solo puede obtener de la base de datos la información que tiene datos para generar". Entonces, primero diseño la base de datos y luego el código.

¿Por qué? No importa qué metodología / lenguaje / conjunto de herramientas use, si todos los datos relevantes están bien diseñados y almacenados en la base de datos, puedo recuperarlos. No importa si está en C # / Delphi / FORTRAN / COBOL / Assembly / VBA o Crystal Reports; OO diseñado o evento / datos / lo que sea impulsado; ágil o cascada. Si los datos están allí, puedo recuperarlos si las herramientas que uso pueden conectarse a la base de datos. Puedo crear los informes de ventas si puedo SELECCIONAR los pedidos para los ingresos del trimestre, incluso si tengo que escribirlo byte por byte en la Asamblea.

Si los datos relevantes no están allí o incluso si están allí, pero (des) estructurados de una manera que no puedo recuperar la información que necesito, ¿cómo codificarla?

Como de costumbre, depende;)

Por ejemplo, supongamos que tenemos un prototipo de trabajo de pequeño tamaño desarrollado en Python y que utiliza archivos planos, y los usuarios están contentos con las características del prototipo, por lo que todo lo que tenemos que hacer es producirlo, utilizando RDBMS como back-end. . Cuando este es el caso, es razonable esperar hacerlo bien la primera vez; el problema es pequeño y está bien definido. En tales casos, el diseño por adelantado es factible.

Por otro lado, cuando descubrimos los requisitos en un entorno ágil, necesitamos algunas iteraciones para comprenderlos mejor. En tales situaciones, la base de datos evoluciona con el resto de la aplicación. Esto es lo que solemos hacer. Debido a que podemos refactorizar tablas OLTP en vivo sin ningún tiempo de inactividad y con bajo riesgo, nos sentimos cómodos con la posibilidad de refactorizaciones de bases de datos.