Al hacer TDD y agregar funciones de forma incremental, ¿diseño la base de datos o agrego tablas y columnas durante la codificación?

Una de las oportunidades más importantes que TDD nos brinda, desde mi punto de vista, es desarrollar proyectos de forma incremental, agregando características una a una, lo que significa que idealmente tenemos un sistema en funcionamiento en cada momento.
Lo que estoy preguntando es, cuando el proyecto implica trabajar con una base de datos, ¿podemos usar este enfoque incremental para crear la estructura de la base de datos o debemos trabajar la estructura antes de comenzar a escribir el código? Sé que es difícil predecir cómo será la estructura de la base de datos dentro de 1 año, pero en general, ¿cuál es la mejor práctica?Al hacer TDD y agregar funciones de forma incremental, ¿diseño la base de datos o agrego tablas y columnas durante la codificación?

Fuente

2010-02-27 chester89

(+1) buena pregunta – skaffman

Me encanta cómo las dos primeras respuestas están en oposición directa entre sí. – aehiilrs

Entireley depende de a quién le preguntes. Bob Martin, Martin Fowler y todos parecen estar en el campo 'Crea siempre tus objetos primero, base de datos posterior'. Yo creo que Joe Celko estaría del otro lado de la valla. Ambos hacen afirmaciones válidas de por qué seguirías su enfoque. –

El beneficio de TDD y YAGNI es que adresses explícitamente la cuestión de que nosotros, como desarrolladores, no podemos predecir las necesidades futuras. Eso es tan cierto para el diseño de bases de datos relacionales como para el código orientado a objetos.

La base de datos es un detalle de implementación. Su único propósito es apoyar la aplicación proporcionando servicios de persistencia. Si no sabe qué va a hacer su código dentro de tres meses, sería ilusorio pensar que sabe cómo se verá su base de datos.

Fuente

2010-02-27 09:55:42

No - el propósito de una base de datos es almacenar datos, * ese es * su propósito principal. La interacción de la aplicación es secundaria. Refactorizar el almacenamiento de datos es difícil. – skaffman

Es bastante fácil predecir los requisitos futuros. No veo por qué querrías perpetuar semejante mito. –

Sí, el almacenamiento de datos de refactorización es difícil, y si pudiera resolver el problema con BDUF y hacerlo bien de una vez, preferiría eso. Sin embargo, nunca he podido hacer eso con éxito, y no he conocido a nadie que pudiera hacerlo. –

La respuesta aquí es bastante obvia, en lo que a mí respecta.

Usted diseña la estructura de la base de datos. TDD, en cierta medida, no se trata de probar la lógica (lógica en la cabeza) se trata de probar la implementación y asegurarse de que se mantenga constante.

Diseñar una base de datos, al igual que con el diseño de cualquier cosa, se trata de corregirla de forma lógica y conceptual. Es decir. asegurándose de tener los campos correctos, que la tabla será útil, que asegura e implica el tipo correcto de relaciones, y que permite todo tipo de acciones que desee.

Por lo tanto, antes de escribir cualquier código, necesita tener esta "cosa" para saber lo que hará su código. Por lo tanto, se deduce trivialmente que primero haces la base de datos y luego escribes el código para probarla.

Quizás se mostrará, a través de pruebas, que se le olvidó algo. De acuerdo, esto es bueno y apropiado; así que regrese y agréguelo, y luego continúe probando.

Fuente

2010-02-27 09:55:09

La diferencia aquí es que la refacturación de una base de datos generalmente es considerablemente más difícil que el código de refactorización – skaffman

@skaffman: a veces puede ser más difícil. A veces no. Quiero decir, claramente es una tontería diseñar parte de una mesa, luego probarla, luego diseñar el resto. Claramente tiene sentido diseñar e implementar componentes de su sistema, en el DB, luego asegúrese de que todos funcionen y luego agregue más. No estoy sugiriendo que hagas que tu base de datos sea perfecta desde el día 1 (por supuesto, no es prudente ni siquiera es necesario luchar por esto, en general). Te digo que completes un modelo dado y luego lo implementes. Repita hasta que el proyecto esté completo. –

Para mí, esta es una pregunta con una respuesta "teórica" y una respuesta del "mundo real".

En teoría, agrega una columna cuando lo necesite y refactoriza su base de datos sobre la marcha, porque eso es ágil.

En el mundo real, sus DBA lo matarán si tienen que reconstruir los datos de prueba cada cinco minutos porque ha cambiado el esquema nuevamente. Y en un proyecto más pequeño, te cansarás personalmente de tener que dedicar la mitad de tu tiempo a mantener una base de datos inestable.

Como aludió skaffman en un comentario: el mantenimiento de la base de datos es generalmente más costoso que el mantenimiento del código. Esto es doblemente cierto para la implementación: puede rodar una nueva aplicación completa sin ningún problema, pero intente planificar una actualización de la base de datos en vivo sin romper sus datos.

Es una discusión difícil, porque los puristas ágiles insistirán en que todo debe hacerse "justo a tiempo". Pero, como en la mayoría de las cosas ágiles, la realidad es que alguien necesita estar anticipando la próxima versión.Las prioridades cambian, pero si no hay al menos una vaga idea de cómo se verá el producto en 6 meses, entonces tienes problemas mayores que la metodología de desarrollo ...

El papel de un arquitecto (o líder tecnológico, o jefe de DBA, o el sabor que tengas) es mirar hacia adelante esos pocos meses y planear para lo que estás seguro en un 90%, y parte de eso definirá los datos que vas a necesitar y dónde es probable que vivir.

Entonces, quizás en lugar de agregar una columna a la vez, agregue una tabla a la vez. Encuentre el equilibrio que se adapte a su proyecto y a su proceso de desarrollo, sin duplicar su carga de trabajo.

Fuente

2010-02-27 10:10:31

* En el mundo real, sus DBA lo matarán si tienen que reconstruir sus datos de prueba cada cinco minutos porque ha cambiado el esquema nuevamente * Dispararía un DBA de ese tipo y obtendría un DBA Ágil real (o no DBA en absoluto) para un pequeño proyecto). –

Bueno, sí, en un proyecto pequeño, no necesita un DBA. En un gran sistema de producción con millones o miles de millones de filas, hacer un mantenimiento constante porque los desarrolladores no pueden arreglar su esquema por más de una quincena es probable que cause frustración. Mi intención era señalar que la migración de datos necesaria si se cambian los esquemas a menudo es un verdadero dolor, y el costo/beneficio de eso empeora cuanto más grande es el proyecto. –

Primero, lo que está describiendo en su respuesta es BDUF, eso es simplemente anti Ágil. Y no tiene que suceder, incluso en un gran proyecto (lo hice en un gran proyecto financiero). En segundo lugar, el equipo debe tener el control, no un arquitecto, un líder tecnológico o un jefe de DBA. No hay tal cosa en Agile. El equipo decide –

Si sus tablas están en la forma normal de Boyce-Codd o mejor, entonces deben ser utilizadas con bastante facilidad por cualquier aplicación sin modificaciones, suponiendo que realmente almacenan los datos necesarios. El objetivo de las bases de datos relacionales y el modelado relacional es desarrollar un modelo de datos independiente de las rutas de búsqueda de cualquier aplicación o consultas de uso común.

Y es bastante fácil diseñar una base de datos correctamente normalizada "desde el principio", al menos si conoce los datos que se administran por adelantado.

La única razón por la que necesitaría "refactorizar" un esquema RDBMS es si el diseño original era prima facie inaceptable para cualquier ojo competente. Ahora, algunos espacios de tabla o indexación pueden necesitar ser modificados, pero eso no tiene nada que ver con el diseño.

Fuente

2010-02-27 10:57:37

Hasta que la base de datos BCNF correctamente normalizada no funcione bajo carga. Todo el tablespace y el ajuste de índices en el mundo no pueden salvarte en algunos casos. El volumen de datos, su distribución y su uso también es una dimensión del diseño adecuado. –

Debería haber agregado vistas actualizadas materializadas, por supuesto. En el punto que describes, no tiene sentido utilizar un RDBMS convencional, por lo que la cuestión de cómo evolucionar su esquema es discutible. Tampoco es un punto fácil de alcanzar, a menos que esté haciendo bioinformática o Facebook ... –

Sí, porque el costo de $ CURRENCY para hardware -y el costo de licenciar un RDBMS- tampoco es una consideración. Simplemente arroje dinero/hardware hasta que rinda mejor, porque los presupuestos son infinitos. –

¿Podemos usar este enfoque incremental para crear la estructura de la base de datos o debemos trabajar la estructura antes de comenzar a escribir el código?

Sí, puedes (echar un vistazo a Fowler's Evolutionary Database Design). Y no, no deberías trabajar en la estructura por adelantado (esto es BDUF). Scott Ambler también ha escrito mucho sobre esto y sobre las técnicas que permiten aplicarlo en términos reales. Chek out Agile Database Techniques, Refactoring Databases: Evolutionary Database Design y The Process of Database Refactoring: Strategies for Improving Database Quality por ejemplo.

Y como dije en un comentario, si a su DBA no le gusta (si actúa con el modelo y datos como Gollum con el precioso), obtenga otro DBA, un DBA que comprenda el trabajo de Fowler y Ambler. Período.

Fuente

2010-02-27 11:09:15

Tengo. Y esas personas no entienden la diferencia entre el costo de refacturar los sistemas de escala departamental, versus, por ejemplo, un sistema de tarjeta de crédito con miles de millones de registros y cero requisitos de tiempo de inactividad. Es análogo a la diferencia entre la química y la ingeniería química. Es trivial extender un modelo normalizado; no es trivial eliminar columnas en todos los motores de base de datos. En DB2 desde hace unos años, tendrías que dejar la tabla, e incluso el DB2 moderno requerirá eventualmente sacar la tabla fuera de línea. Sin embargo, las bases de datos totalmente normalizadas tienden a tener bajo rendimiento y alta complejidad –

Sí, Fowler y Ambler son conocidos por su incomprensión de los problemas de la vida real ... Y, por cierto, la pregunta era sobre desarrollo, no un sistema en vivo (y si su base de datos no tolera el cambio y no es compatible con su metodología; bueno, ¿qué puedo decir, excepto que no lo use?). –

Las bases de datos, mucho más que el código, son sistemas en vivo. Una vez que haya realizado la primera implementación, la refacturación será mucho más complicada que cambiar la implementación detrás de las interfaces, porque la implementación es la interfaz. –

Se pueden tomar varios enfoques para reducir la dificultad de refactorizar la base de datos para que coincida con el código que genera TDD. Considere generar su base de datos a partir de las clases que crea como parte del proceso TDD.

Otra posibilidad es generar su base de datos, datos de prueba, y posiblemente incluso el código de repositorio básico, desde un modelo conceptual de base de datos usando una herramienta como NORMA. El "ORM" aquí es el Modelo de Objeto-Rol (el "otro" ORM), y NORMA es un complemento de Visual Studio que puede generar DDL y código a partir de un modelo conceptual.

Lo bueno es que, incluso si el modelo conceptual cambia significativamente (una relación que se convierte en muchos a varios, por ejemplo), tanto el código como el DDL cambiarán para reflejar eso.

Fuente

2010-02-27 11:09:40

Al hacer TDD y agregar funciones de forma incremental, ¿diseño la base de datos o agrego tablas y columnas durante la codificación?

Respuesta

Cuestiones relacionadas