Usando una base de datos común para el desarrollo colaborativo

Question

Algunas de las personas en mi proyecto parecen pensar que usar una base de datos de desarrollo común con todos los que se conectan es lo mejor. Creo que no lo es y cada desarrollador que tenga su propia base de datos (con volcados de datos actualizados periódicamente) es lo mejor. ¿Estoy en lo correcto o incorrecto? ¿Ha encontrado algún problema en alguno de estos enfoques?

Answer 1

El espacio en disco y la CPU deberían ser lo suficientemente baratos como para que cada desarrollador pueda ejecutar su propia instancia de la base de datos , con una compilación automatizada bajo control de versiones. Esto es necesario para permitir a los desarrolladores ser intrépidos en la piratería de la base de datos, aisladamente de la piratería simultánea de cualquier otro desarrollador.

La advertencia es, por supuesto, que cualquier cambio que realicen en su instancia privada no sirve para nadie a menos que se pueda aplicar automáticamente durante el proceso de compilación. Por lo tanto, debe existir una política firme de que el código de la aplicación no puede depender de ningún estado de la base de datos a menos que ese estado esté representado por cambios controlados por la versión y probados por la unidad en DDL .

Para obtener una excelente guía sobre la teoría y la práctica de tratar la definición de la base de datos como otra parte del código del proyecto y coordinar los cambios y refactorizaciones, consulte Refactorización de bases de datos: diseño de bases de datos evolutivas por Scott W. Ambler y Pramod Sadalage.

Answer 2

Me gusta tener mi propia copia de la base de datos para el desarrollo, porque le brinda la flexibilidad de cambiar rápidamente las cosas sin preocuparse de cómo impactará a los demás.

Sin embargo, si todos los desarrolladores están pirateando su propia copia de la base de datos, se vuelve cada vez más difícil fusionar el trabajo de todos juntos al final.

Creo que puede obtener lo mejor de ambos mundos al permitir que los desarrolladores trabajen en una copia local durante el desarrollo diario, pero cada desarrollador probablemente debería fusionar su trabajo en una copia común de manera bastante regular. Escribir muchas pruebas unitarias también ayuda.

Answer 3

Compartimos una única base de datos entre todos nuestros desarrolladores (20 o más) pero la estructuramos para que todos tengan sus propias tablas.

No necesita una base de datos separada por desarrollador si estructura la aplicación correctamente. Debe ser configurable qué base de datos o prefijo de tabla utiliza de todos modos para que pueda moverlo fácilmente entre instancias (prueba de unidad, prueba de sistema, prueba de aceptación, producción, recuperación ante desastres, etc.).

La ventaja de usar una sola base de datos es que el costo de mantenimiento se amortiza. No tiene sus DBA tratando de manejar una gran cantidad de bases de datos (o, si es una tienda de base de datos pequeña, no tiene todos los desarrolladores que intentan mantener su propia base de datos cuando se utilizan mejor en el desarrollo).

Answer 4

Tener un solo punto de falla no es algo bueno, ¿no?

Answer 5

Prefiero una única base de datos compartida. Pero depende mucho de la situación y de las aplicaciones que se desarrollen.

Lo que funciona para mí puede no funcionar para usted. Ve con tu instinto.

Answer 6

Si está trabajando con Hibernate o cualquier plataforma basada en hibernate, puede configurar su base de datos para que se cree cuando inicie su servidor (opción crear-soltar). Esto es muy útil cuando agrega nuevos atributos a sus clases. Si este es el caso, cada desarrollador debe tener su propia copia de la base de datos.

Si no está cambiando la estructura de la base de datos, puede usar una única base de datos compartida. En este segundo caso no es imprescindible. Prefiero tener mi propio DB donde puedo hacer lo que quiera. Por otro lado, recuerde que algunas consultas pueden llevar mucho tiempo y esto afectará a todo su equipo si comparte una base de datos.