Renommer une colonne ou append une colonne? telle est la question

Je pense que le moyen le plus sûr de le faire est de créer une nouvelle table et de créer de nouvelles procédures et methods stockées .

Mais il est préférable de comprendre tout le système … Mettre des pansements comme celui-ci va devenir un gros problème avec le time.

Créer de nouvelles tables, procédures stockées et methods est un désordre plus propre que d'append / modifier des choses à existant.

EDIT: J'ai travaillé sur quelques applications Web qui ont eu le même problème. Plusieurs développeurs avant moi ont ajouté et modifié un tas de choses dans leur propre style. Je suppose que votre cas est similaire.

Comme je l'ai dit. Le meilleur moyen est de comprendre l'set du système et de le modifier. Mais si vous ne pouvez pas, je trouve préférable d'append de nouveaux modules plutôt que de modifier existant. Il est facile de le détwigr quand quelque chose ne va pas. Aussi, au less maintenant vous savez exactement comment fonctionne votre module.

Si l'application existante est très bien écrite et facile à étendre, je suppose que vous ne poseriez pas la question ici.

Alors … mes pensées finales.

• Best: Renommez la colonne et modifiez-la en conséquence (si vous savez exactement comment fonctionne le système)
• Sûr: Ajouter de nouvelles colonnes
• Plus sûr: Ajouter une nouvelle table pour les nouvelles colonnes et créer de nouvelles methods (override ou overload)

Si vous devez vraiment faire cela, allez avec l'option deux à coup sûr .

Pour l'anecdote, je pense que faire un changement de structure à un db que vous ne comprenez pas est une recette pour le désastre , alors bonne chance!

Recherchez dans le code source les references à la colonne que vous souhaitez renommer.
Je suppose que tout le code source est dans un référentiel source. (Y compris les scripts SQL.).

Si vous en trouvez, vous devez les changer et tester cette fonctionnalité.

En outre, je donnerais à la fonctionnalité liée à ceci un test raisonnable dans un environnement de test, après avoir fait ces changements.

Si vous ne faites pas cela, vous devriez vraiment aller avec votre deuxième option.

Solution idéale: Comprendre les 90% restants du système 🙂

J'appendais les deux nouvelles colonnes et laisserais la colonne OLD mal orthographiée comme elle est. Même si votre nouvelle logique utilise votre nouvelle colonne (fixe), qu'en est-il des anciens rapports? Ancienne logique? Anciennes instructions d'insertion / mise à jour?

Si vous ne comprenez pas le schéma de la database, ne le renommez pas. Qui sait ce que vous allez casser 🙂

Une option (un peu folle) consiste à append votre colonne qui est simplement un renommage, à y copyr datatables actuelles, puis à redessiner la colonne d'origine afin que ce soit un champ calculé qui renvoie la valeur de la nouvelle colonne.

De cette façon, vous obtenez le renommer, mais vous ne supprimerez pas l'ancienne colonne.

Le pari le plus sûr est de changer cela. Faites de votre nouvelle colonne une valeur calculée qui ne fait que lire l'ancienne et en finir avec elle 🙂

Ou, vous pourriez créer une vue qui ferait à peu près la même chose.

Vous savez, j'ai travaillé sur un système où nous avons simplement laissé l'ancien en place, puis ajouté le nouveau et utilisé à l'avenir. Cela crée un plus grand désordre à long terme que de faire le changement, puis de changer toutes les references à l'ancienne structure. Alors maintenant, ils ont un système où ils ne peuvent standardiser quoi que ce soit de nouveau parce qu'il y a quatre structures différentes pour stocker des informations sur les haut-parleurs et deux structures différentes pour stocker les informations de rep, etc. Chaque petit changement doit être personnalisé par le client. beaucoup plus difficile à maintenir dans le futur. Ce n'est pas efficace ou efficient et il devient beaucoup plus coûteux à entretenir. Mordez la balle et découvrez ce qui sera affecté, puis tout changer à la fois.

Voici une bonne présentation sur les bases de données de refactoring par Scott Ambler, le gars qui a littéralement écrit le livre sur les bases de données de refactoring.