0
votes

Renommer la table ou la colonne de SQL Server sans casser les applications existantes

J'ai une base de données existante dans MS SQL Server et je souhaite renommer des tables et des colonnes car les noms actuellement utilisés ne sont pas exacts à ce qu'il représente.

J'ai plusieurs applications Web et de bureau qui accèdent à la base de données, à l'aide du cadre d'entité (code en premier). Trop nombreux pour mettre à jour en une fois et ne peut pas se permettre pour toutes les applications de commencer à travailler.

Je pensais que c'était bien, SQL Server a permis à SQL Server autorisait un alias «permanent» pour les tables et les colonnes, mais je ne pense pas que cette fonctionnalité existe.

ou je me demandais s'il y avait un moyen d'avoir deux noms pour la même propriété?


1 commentaires

Vous pouvez renommer les tables à n'importe quoi - mais créez ensuite une vue qui accède aux données de ces tables avec le nom aliasé.


3 Réponses :


3
votes

Pour les tables, vous pouvez les renommer, puis créer un synonyme avec l'ancien nom pointant vers le nouveau nom.

Pour les colonnes, la modification de leur nom brisera votre application. Vous pouvez également créer des colonnes calculées avec l'ancien nom, qui affiche simplement la valeur de la nouvelle colonne nommée (mais cela semble un peu idiot).

Remarque, toutefois, une colonne calculée ne peut pas faire référence à une autre colonne calculée, vous devez donc dupliquer la colonne de son intégralité. Cela pourrait entraîner des problèmes dans la ligne si vous ne mettez pas à jour la définition des deux colonnes.


5 commentaires

Merci pour cela, cela a répondu à ma grande exigence, je ne peux pas croire que je ne suis jamais survint de synonymes avant!


En ce qui concerne les colonnes, je pense que je vais créer une nouvelle colonne avec les mêmes données de l'ancienne colonne et utiliser des déclencheurs pour conserver les données de colonne sous Sync jusqu'à ce que je puisse mettre à jour toutes les applications pour utiliser les nouveaux noms de colonne.


Les déclencheurs sembleraient une mauvaise idée @user. C'est des frais généraux inutiles.


L'ajout de nouvelles colonnes et peupler avec des déclencheurs n'est pas la meilleure option. Vous n'avez pas besoin de dupliquer les données. C'est trop sujette à une erreur. Cela semble également être plus important de conserver les deux colonnes en synchronisation.


Vous n'avez même pas besoin d'une gâchette, juste une colonne calculée. Mais c'est toujours une mauvaise idée



0
votes

Une vue contenant une instruction sélectionnée simple agit exactement comme une table. Vous devez vraiment résoudre ce problème correctement sur la base de données et les applications. Toutefois, si vous voulez aller la voie de vue, je vous suggère de faire ceci:

Dites que vous avez une table appelée MyTable que vous renommez Thetable et avec une colonne appelée < Code> myColumn que vous souhaitez renommer à thecolumn

  1. Créer un schéma, disons, nouveau
  2. Déplacez la table d'origine avec ce Alter Schéma Nouveau transfert MyTable
  3. renommer la table et la colonne.

    Vous avez maintenant une table appelée nouvelle.Thettable avec une colonne appelée thecolumn . Tout est cassé

    enfin, créez une vue qui ressemble à l'ancienne table xxx

    maintenant tout fonctionne à nouveau.

    • Tous vos tables "nouvelles" fixes sont dans le nouveau schéma
    • Cependant, tout est extra compliqué

      Ceci est essentiellement une illustration que vous devriez simplement le réparer correctement sur toute l'application une à la fois avec une gestion de changement minutieuse. Certainement, ne le compliquez pas avec des déclencheurs


0 commentaires

0
votes

Étant donné que vous utilisez le code d'abord avec plusieurs applications Web et de bureau, vous avez probablement la gestion probable des changements de base de données d'un endroit via les migrations et en ignorant les modifications autres lieux. Vous pouvez créer une migration vide et ajouter du code qui modifiera le nom de la table et les noms de colonne à ce que vous voulez. La migration devrait alors créer une vue qui choisira à partir de cette table avec la table d'origine et les noms de colonne. Lorsque vous appliquez cette migration, tout doit toujours fonctionner normalement de toutes les applications. Il n'y a pas de changements de modèle depuis que vous n'avez pas touché les classes de modèle. Les insertions, les mises à jour et les suppressions se produiront toujours à travers la vue. Il n'y a pas besoin de déclencheurs potentiellement buggy ni de synonymes sur la table dans cette option. Maintenant que la table a changé, vous pouvez vous concentrer sur le code de l'application. Si cela aide, vous pouvez ajouter des annotations sur la colonne et les noms de table et commencer à refactoriser le code. Vous devez vous assurer de ne pas faire de modifications modèles qui vont briser les autres applications. Si les applications ignorent les modifications du modèle, vous pouvez vous éloigner d'ajouter des annotations sur les colonnes et les classes de toutes les applications avant de refactoriser. Vous pouvez vous débarrasser de la vue plus tôt de cette façon.


0 commentaires