Statégies pour faire face à l'évolution des schémas?

Question

Actuellement, nous utilisons du SQL roulé à la main dans les objets Data-Access et beaucoup de procédures stockées et de déclencheurs qui représentent environ 20k lignes de code. Nous constatons que de simples changements causent quelques jours de travail à corriger, et que les échéances sont en train de glisser.

Les modifications incluent des modifications de tables pour gérer des données supplémentaires, un refactoring général du schéma basé sur les rapports QA/user, etc. C'est un système très actif qui est en cours de construction pour remplacer quelque chose de vieux et lent.

Nous avons examiné les solutions PHP ORM disponibles pour essayer de limiter les effets de ces changements, mais ils étaient trop lents pour faire face à notre schéma; Les résultats SQL "simples" prenaient des ordres beaucoup plus longs à renvoyer que nos requêtes personnalisées et les pages vues de ~ .5s prenaient plus de 20 secondes. Quelles meilleures pratiques/stratégies pourrais-je envisager pour faire face à l'évolution des schémas avec des bases de données relationnelles, dans un contexte général?

Édition: oublié de mentionner les déclencheurs; nous avons beaucoup de données qui repose sur des changements en cascade, par exemple. un changement de prix ici pour cet utilisateur met à jour un prix il pour que utilisateur, etc.

Answer 1

Vous voudrez peut-être vérifier ce livre sur Refactoring Databases: Evolutionary Database Design.

Answer 2

Mon conseil serait de se débarrasser des procédures stockées SQL et utiliser à la place en ligne, peut-être maintenu dans des fichiers texte/xml. Je trouve que les SProcs sont beaucoup plus ennuyeux et prennent beaucoup de temps à maintenir. Une fois le plan de requête généré (la première fois que la requête est exécutée), vous remarquerez une différence de performance négligeable. De plus, vous serez en mesure de contrôler la version de tous vos scripts DB ...

Answer 3

Je suggère d'utiliser une stratégie continue (ou au moins tous les soirs).
Reconstruisez la base de données à chaque vérification, ou au moins une fois par jour.
Également une fois par jour, exécutez des tests unitaires pour exercer chaque bit de code, que ce soit dans une procédure stockée, un déclencheur ou une couche d'accès aux données.

L'écriture de procédures stockées coûte très cher, mais cela permet d'identifier immédiatement les interruptions.
Une fois que vous savez où est la pause, vous pouvez le réparer.

Je serais intéressé d'entendre les expériences d'autres personnes avec cette stratégie appliquée aux changements de base de données.

Answer 4

Nous utilisons Enterprise Architect pour nos définitions de base de données. Nous incluons les procédures stockées, les triggers et toutes les définitions de tables définies dans UML. Les trois caractéristiques brillantes du programme sont:

1. Importer des diagrammes UML à partir d'une connexion ODBC.
2. Générer des scripts SQL (DDL) pour l'ensemble du DB en une fois
3. Générez une documentation personnalisée sur le modèle de votre base de données.

Je n'ai jamais été plus impressionné par aucun autre outil dans mes 10 ans et plus en tant que développeur. EA prend en charge Oracle, MySQL, SQL Server (plusieurs versions), PostGreSQL, Interbase, DB2 et Access d'un seul coup. Chaque fois que j'ai eu des problèmes, leurs forums ont rapidement répondu à mes problèmes. Hautement recommandé!! Lorsque les changements de DB arrivent, nous faisons alors dans EA, générons le SQL, et le vérifions dans notre contrôle de version (svn).Nous utilisons Hudson pour la construction, et il construit automatiquement la base de données à partir des scripts lorsqu'il voit que vous avez modifié le sql enregistré.

Answer 5

Voici mes suggestions:

1. Essayez de vous débarrasser des moins fonctionnalités utilisées. Interrogez les fonctionnalités qui ne sont pas utilisées tout le temps. Chaque fonctionnalité d'une application est associée à plusieurs niveaux de coûts (maintenance, support, tests de régression, complexité du code, etc.).
2. Restez à l'écart des procédures stockées, à moins qu'il n'y ait absolument aucun moyen de le faire efficacement et de manière évolutive dans le code.
3. introduisons une solution ORM progressivement (en utilisant refactoring pour passer de JDBC à ORM) pour réduire la quantité de code et la complexité du code dans les opérations CRUD
4. Construire fonctionnelle, intégration et tests unitaires comme et quand vous corriger un bug et incorporer les tests dans le système d'intégration continue. Automatisez autant que possible vos tests de régression pour identifier les problèmes dès qu'ils sont introduits par un check-in.
5. En général, chaque fois que vous corrigez un bogue, utilisez cette possibilité pour refactoriser les modules d'implémentation/code.

Si vous avez avez des questions sur les problèmes de migration de base de données, cela pourrait aider: http://shashivelur.com/blog/2008/07/hibernate-db-migration/