Conseils sur la refactorisation d'un schéma de base de données obsolète [fermé]

Question

Le cauchemar de chaque développeur est de se retrouver avec un schéma de base de données hérité qui ne correspond plus à votre modèle de données. Pourtant, avec toutes les discussions sur le refactoring du code pour la maintenabilité, je n'ai pas beaucoup entendu parler du refactoring des schémas de bases de données obsolètes.

Quels sont quelques conseils pour passer à un meilleur schéma sans détruire tout le code reposant sur l’ancien? Je vais proposer un problème spécifique pour lequel je dois illustrer mon propos, mais n'hésitez pas à donner des conseils sur d'autres techniques qui se sont révélées utiles - elles seront également utiles.

Mon exemple:

Mon entreprise reçoit et expédie les produits. Maintenant, un reçu de produit et une expédition de produit ont des données très différentes qui leur sont associées. Par conséquent, les concepteurs de base de données d'origine ont créé un tableau séparé pour les réceptions et les envois.

Au cours de ma première année de travail avec ce système, je me suis rendu compte que le schéma actuel n’a pas de sens. Après tout, un reçu et un envoi sont essentiellement des transactions, ils impliquent chacun de modifier la quantité d'un produit, seul le signe +/- est différent. En effet, il est souvent nécessaire de déterminer le montant total des modifications apportées au produit sur une période donnée, problème pour lequel cette conception est carrément insoluble.

Évidemment, la conception appropriée serait d’avoir une seule table de transactions, l’ID étant la clé étrangère d’une table ReceiptInfo ou d’une table ShipmentInfo. Malheureusement, le mauvais schéma est déjà en production depuis quelques années et contient des centaines de procédures stockées et des milliers de lignes de code. Comment puis-je faire en sorte que le schéma fonctionne correctement?

Answer 1

Voici un catalogue complet de refactorisations de bases de données:

http://databaserefactoring.com/

Answer 2

C'est une chose très difficile à contourner. Quelques options rapides après la refactorisation de la base de données sont les suivantes:

Créez des vues qui correspondent au schéma d'origine mais sont extraites du nouveau schéma. Vous aurez peut-être besoin de déclencheurs ici pour pouvoir gérer les mises à jour des vues.

Créez le nouveau schéma et insérez des déclencheurs de chaque côté pour conserver l'autre côté.

Answer 3

Ce livre (Refactoring des bases de données) a été un message envoyé par Dieu moi lorsque je traite de schémas de base de données hérités, y compris lorsque je devais traiter presque exactement le même problème pour notre base de données d'inventaire.

En outre, la mise en place d’un système permettant de suivre les modifications apportées au schéma de la base de données (comme une série de scripts de modification stockés dans le référentiel de contrôle de source) facilite considérablement la détermination des dépendances entre le code et la base de données.

Answer 4

Les procédures stockées et les vues sont vos amis ici. Même si le système ne les utilise pas, changez-les pour les utiliser, puis refactorisez la base de données située en dessous.

Vos reçus et vos envois deviennent alors des vues.

Attention, les recettes et les envois sont en réalité deux animaux très différents dans la plupart des systèmes avec lesquels j'ai travaillé. Les recettes sont liées aux fournisseurs, tandis que les expéditions sont liées aux clients (ou aux clients / sites de livraison). Au niveau des stocks, ils sont souvent représentés de la même manière.

Answer 5

Tous les accès aux données sont-ils limités aux procédures stockées? Sinon, la tâche pourrait être presque impossible. Si tel est le cas, vous devez simplement vous assurer que vos scripts de migration de données fonctionnent correctement lors de la transition de l'ancien au nouveau schéma, puis vous assurer que vos procédures stockées respectent leurs entrées et sorties.

Nous espérons qu'aucun d'entre eux n'a " select * " requêtes. Si tel est le cas, utilisez 'sp_help tablename' pour obtenir la liste complète des colonnes, copiez-la et remplacez chaque * par la liste complète des colonnes, juste pour vous assurer de ne pas altérer le code client.

Je recommanderais d’apporter les modifications progressivement et de réaliser de nombreux tests d’intégration. Il est difficile de faire un remodelage significatif sans introduire quelques bugs.

Answer 6

La première chose à faire est de créer le schéma de table. Je l'ai déjà fait pour une base de données Legacy utilisant Enterprise Architect. Vous pouvez sélectionner la base de données et elle vous créera toutes les tables / champs. Ensuite, vous devrez tout diviser en catégories. Exemple tous vos reçoit et expédie des produits ensemble, des trucs client dans une autre catégorie. Une fois que tout est clair, vous pourrez refactoriser le champ en créant un nouveau tableau, un nouveau releashionship et de nouveaux champs. Bien sûr, cela nécessitera beaucoup de changements si tout est accessible sans procédure stockée.

Answer 7

Je ne pense pas qu'il soit évident que l'id de la table de transactions soit une clé étrangère à ReceiptInfo ou à ShipmentInfo. Pensez l'inverse. Dans un modèle orienté objet, vous devez avoir une table de transaction et le ReceiptInfo ou un ShipmentInfo doivent avoir une clé étrangère dans la table de transaction. Si vous êtes chanceux, il n'y aura que 1 ou 2 points dans le code où de nouveaux enregistrements dans ReceiptInfo ou un ShipmentInfo sont créés. Vous devez y ajouter le code à l'endroit où vous ajoutez une entrée dans la table des transactions, puis créer cette entrée dans ReceiptInfo ou ShipmentInfo avec la clé étrangère à Transaction.

Answer 8

Parfois, vous pouvez créer de nouvelles tables ayant de meilleures structures, puis créer des vues avec les noms de vos anciennes tables mais basées sur les données des nouvelles tables. De cette façon, votre code ne casse pas pendant que vous commencez à vous déplacer vers une meilleure structure. Soyez prudent avec cela car parfois vous passez d'une table non relationnelle à une structure relationnelle dans laquelle vous avez plusieurs enregistrements alors que le code n'en attend qu'un. Ceci est particulièrement vrai si vous avez des développeurs qui utilisent des sous-requêtes.

Ensuite, chaque fois que vous modifiez une chose, elle s’éloigne des vues pour la table réelle. Finalement, vous pouvez supprimer les vues. Cela vous permet au moins de travailler progressivement pour que les choses se passent lorsque vous déplacez des objets, mais commencez à les réparer pour utiliser un meilleur design.