¿Estrategias para hacer frente a la evolución del esquema?

Question

Actualmente estamos utilizando SQL enrollado a mano en objetos de acceso a datos y una gran cantidad de procedimientos almacenados y disparadores que ascienden a alrededor de 20k líneas de código. Estamos descubriendo que los cambios simples están causando el trabajo de un par de días para solucionar y que los plazos se pierdan.

Los cambios incluyen modificaciones en las tablas para hacer frente a datos adicionales, refactorización general del esquema en función de los informes de control de calidad/usuario, etc. Es un sistema muy activo que se está creando para reemplazar algo viejo y lento.

Analizamos las soluciones PHP ORM disponibles para tratar de limitar los efectos de estos cambios, pero fueron demasiado lentos para hacer frente a nuestro esquema; Los resultados sql "simples" tomaban órdenes de magnitud más larga que nuestras consultas personalizadas y hacían que las vistas de página de ~ .5 tuvieran más de 20 segundos.

¿Qué mejores prácticas/estrategias podría considerar para hacer frente a la evolución del esquema con bases de datos relacionales, en un contexto general?

Editar: se olvidó de mencionar acerca de los factores desencadenantes; tenemos una gran cantidad de datos que se basan en cambios en cascada, por ejemplo. un cambio de precio aquí para este usuario actualiza un precio hay para que usuario, etc.

Answer 1

Es posible que desee consultar este libro en Refactoring Databases: Evolutionary Database Design.

Answer 2

Mi consejo sería para deshacerse de los procedimientos almacenados y en su lugar utilizar SQL en línea, tal vez mantenida en archivos de texto/xml. Encuentro que los SProcs son mucho más molestos y lentos de mantener. Una vez que se genera el plan de consulta (la primera vez que se ejecuta la consulta) notará una diferencia insignificante en el rendimiento. Además, podrás controlar la versión de tus scripts DB completos ...

Answer 3

Sugiero usar estrategia de compilación continua (o al menos cada noche).
Reconstruya la base de datos en cada registro, o al menos una vez por día.
También una vez al día, ejecute pruebas unitarias para ejercitar cada bit de código, ya sea en un procedimiento almacenado, un disparador o una capa de acceso a datos.

Hay un gran costo para escribir procs almacenados, pero esto identificará los cortes inmediatamente.
Una vez que sepa dónde está el descanso, puede solucionarlo.

Me interesaría escuchar las experiencias de otras personas con esta estrategia aplicada a los cambios en la base de datos.

Answer 4

Utilizamos Enterprise Architect para nuestras definiciones de bases de datos. Incluimos procedimientos almacenados, desencadenadores y todas las definiciones de tablas definidas en UML. Las tres características brillantes del programa son:

1. Importación de diagramas UML de una conexión ODBC.
2. Generar secuencias de comandos SQL (DDL) para toda la base de datos a la vez
3. Generar documentación personalizada con plantilla de su base de datos.

Nunca he estado más impresionado con ninguna otra herramienta en mis más de 10 años como desarrollador. EA admite Oracle, MySQL, SQL Server (múltiples versiones), PostGreSQL, Interbase, DB2 y Access de una sola vez. Cada vez que he tenido problemas, sus foros han respondido a mis problemas de inmediato. ¡¡Muy recomendable!!

Cuando entran los cambios de DB, hacemos en EA, generamos el SQL y lo comprobamos en nuestro control de versiones (svn).Usamos Hudson para construir, y construye automáticamente la base de datos a partir de scripts cuando ve que ha modificado el sql registrado.

Answer 5

Aquí están mis sugerencias:

1. tratar de deshacerse de la funcionalidad menos utilizada. Cuestiona las características que no se usan todo el tiempo. Cada característica de una aplicación tiene varios niveles de costos asociados (mantenimiento, soporte, pruebas de regresión, complejidad del código, etc.).
2. Manténgase alejado de los procedimientos almacenados, a menos que no haya absolutamente ninguna manera de hacerlo de manera eficiente y de manera escalable en el código.
3. Introduzca una solución ORM gradualmente (usando refactorización para pasar de JDBC a ORM) para reducir la cantidad de código y complejidad del código en operaciones CRUD
4. Cree pruebas funcionales, de integración y de unidad cuando arregle un error e incorpore esas pruebas en el sistema de integración continua. Automatice sus pruebas de regresión tanto como sea posible para identificar problemas tan pronto como se presenten en un check-in.
5. En general, siempre que arregle un error, use esa oportunidad para refactorizar para desacoplar las implementaciones/módulos de código.

Si usted tiene tiene preguntas acerca de los problemas de migración de base de datos, esto podría ayudar: http://shashivelur.com/blog/2008/07/hibernate-db-migration/