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


57

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


Divide and Conquer con SDLC
Premraj

1
Puede encontrar interesante flywaydb.org . Le permite controlar la versión de su esquema de base de datos.
Thorbjørn Ravn Andersen

Respuestas:


41

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


66
Y la estabilidad es importante, porque los nombres de tablas y vistas, nombres de columnas, nombres de procedimientos almacenados, etc., son la interfaz pública de la base de datos. (Y tarde o temprano habrá muchas aplicaciones compartiendo esa interfaz.)
Mike Sherrill 'Cat Recall'

Diría que este es un enfoque bastante idealizado, mi experiencia es que de vez en cuando ocurre un cambio drástico, lo que debemos ser es ser ágiles y adaptarnos rápidamente a los nuevos requisitos y seguir refactorizando.
zinking

@zinking: lo estoy haciendo lo ágil en este momento.
gbn

@gbn, siento hacer la siguiente pregunta aquí. No tengo idea de cómo manejar el escenario. Por favor, eche un vistazo. stackoverflow.com/questions/46285924/… . Amablemente sugiérame la mejor solución.
RGS

27

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!


44
Ágil y bases de datos van de la mano con advertencias. Ágil es límite para los VLDB: puede que no haya tiempo suficiente para validar y probar los cambios en miles de millones de tablas de filas entre los entregables. Y "desarrollo ágil" no es lo mismo que "cambios
generales

2
No podría estar más de acuerdo con la falta de previsión, pero no creo que sea relevante para la pregunta. No se trata de si debe abordar el diseño de manera casual, sino de si su modelo de datos debe evolucionar o no a medida que lo hace la aplicación. Los problemas de VLDB justifican una edición que agregaré.
Mark Storey-Smith

3
Leí la pregunta como "una nueva aplicación sin DB todavía" en lugar de "una aplicación existente que requiere cambios en la DB"
gbn

Del mismo modo, me estoy perdiendo su punto en alguna parte :) ¿Uno para llevar al chat?
Mark Storey-Smith

44
+1 para el sentimiento general de su respuesta, pero "Modificar un esquema de base de datos nunca ha sido tan fácil como modificar código" realmente depende de la cantidad de código que tenga (y de la antigüedad que tenga). En mi opinión, lo contrario es más cierto en general
Jack Douglas el

12

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.


77
Agregar muchos requisitos nuevos durante el curso de un proyecto no es "inapropiado". Es algo que sus métodos de desarrollo deberían apoyar y fomentar www.agilemanifesto.org/principles.html
nvogel

1
Conozco algunos de los principios del desarrollo ágil y los he defendido en una capacidad de almacenamiento de datos donde tiene sentido para el negocio. Gracias por tu comentario.
RobPaller

11

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.


+1 Gran respuesta. El desarrollo de requisitos facilitados es un ENORME plus en un proyecto de múltiples partes interesadas.
Zayne S Halsall

10

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.


2
¿No cree que se necesitaría un pensamiento inicial para definir el modelo conceptual?
gbn

Algún pensamiento inicial puede ser útil, pero intentar definir el modelo completo por adelantado suele ser contraproducente. El modelo debe alinearse con los requisitos del negocio y adaptarse a los entregables del proyecto (aplicación incluida) a medida que evolucionan. No puedes ni debes esperar que esas cosas no cambien. Además, crear todo el modelo por adelantado en realidad puede obstruir otro desarrollo debido a la necesidad de crear interfaces ficticias para admitir partes del esquema aún no utilizadas.
nvogel

Sospecho de @dportas y trabajo en entornos similares :)
Mark Storey-Smith

9

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.


1
@RolandoMySQLDBA, ¿está asumiendo que un diseño de base de datos creado durante el desarrollo de la aplicación será un diseño peor que uno construido antes? ¿Por qué? Lo contrario es a menudo cierto.
nvogel

1
@dportas: mi énfasis está en la opción 1 en términos de minimizar los cambios en el diseño de la base de datos. Pasé 2/3 de mi programación de carrera tecnológica en tiendas donde los modelos de datos muy complejos y la infraestructura se transformaban casi mensualmente por capricho. Me estremecí con tales cambios porque las necesidades y objetivos del negocio no estaban grabados en piedra. Soy bastante vieja escuela en esto. No tiene nada de malo ser un poco inconformista, siempre y cuando el diseño no produzca una gran cantidad de "deuda técnica" (sí, leí su respuesta) en el futuro.
RolandoMySQLDBA

2
+1 para 'usar un RDBMS como una base de datos relacional, no un depósito de bits para matrices', cualquiera que sea el enfoque que adopte
Jack Douglas el

2
@dportas: si bien esto es cierto (cambio de reglas de negocio), una base de datos bien diseñada no cambiará radicalmente entre una iteración (o sprint, o lo que sea) y otra, ya que refleja todas las estructuras de datos relevantes del proceso de trabajo. Si esto sucede (cambio radical), significa una falla en las reglas comerciales que capturan actividades.
Fabricio Araujo

3
@dportas: no todos los cambios en la base de datos, solo los RADICALES. Los cambios menores son parte del negocio de hacer software. Pero tener que dividir los datos en 2 bases de datos diferentes en el medio del trabajo es una falla en el diseño y la captura de las reglas comerciales. (En realidad me pasó a mí.
Fabricio Araujo

9

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)


1
El caso de la opción 2 es que con una metodología ágil no se conoce 1, 2 o 3 más allá del alcance del próximo sprint. El cambio es inevitable, en alcance, requisitos y expectativas.
Mark Storey-Smith

8

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?


7

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.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.