Est-ce une bonne idée d'utiliser des synonymes pour éviter de créer un tableau en double?

13

Nous avons 3 copies de la même base de données exacte. Les 3 bases de données ont une Userstable et un utilisateur existera toujours dans les 3 bases de données avec exactement les mêmes paramètres. Chaque fois que nous voulons ajouter ou modifier un utilisateur, nous devons mettre à jour 3 bases de données.

Serait-il préférable de supprimer la Userstable des bases de données 2 et 3 et de la remplacer par une Synonymqui pointe vers la base de données 1?

Voici les avantages / inconvénients auxquels je peux penser:

Avantages

  • Maintenance simplifiée. Peut mettre à jour les utilisateurs dans un seul endroit au lieu de 3
  • Les ID utilisateur correspondraient aux bases de données (important car de nombreuses applications complémentaires sont basées sur UserId)

Les inconvénients

  • Ne pensez pas qu'il s'agit d'une procédure standard, cela pourrait donc prêter à confusion
  • Les utilisateurs devraient avoir des paramètres identiques entre les bases de données
  • (D'après la réponse de gbn ci-dessous) Si la base de données 1 tombe en panne, les bases de données 2 et 3 seront également indisponibles. Il existe également un problème potentiel d'incohérence des données en cas de restauration

C'est une option que j'envisage pour quelques tables différentes contenant des paramètres identiques entre les bases de données, pas seulement la Userstable. J'utilise les utilisateurs dans l'exemple car il est facile à comprendre.

sql-server database-design Rachel
la source
3
Serait-il plus logique d'avoir un script pour synchroniser / fusionner les différences entre eux? Personnellement, je n'aime pas faire dépendre 2 bases de données d'une troisième à cause d'un synonyme comme celui-ci.
FrustratedWithFormsDesigner
@FrustratedWithFormsDesigner Cela semble beaucoup plus de travail, et il est difficile de fusionner les modifications apportées aux champs générés automatiquement tels qu'une clé primaire.
Rachel
Cela dépend de la fantaisie que vous souhaitez obtenir. Si vous souhaitez partager les changements entre eux, alors oui, cela peut devenir compliqué. Si vous voulez en désigner un comme maître, il s'agit simplement d'écraser le contenu des autres avec le contenu du maître.
FrustratedWithFormsDesigner
@FrustratedWithFormsDesigner Malheureusement, l'application est une source fermée et rien n'empêche les gens d'ajouter ou de modifier des utilisateurs dans une base de données. Je devrais faire les changements dans les deux sens car tout le monde a la possibilité de changer son propre mot de passe, et presque tous les gestionnaires ont accès à la gestion des utilisateurs pour ajouter / modifier des utilisateurs.
Rachel

Réponses:

6

Pourquoi avez-vous 3 bases de données avec les mêmes utilisateurs?

Que se passe-t-il si une base de données tombe en panne maintenant?

Je pose ces questions parce que le Con de la base de données utilisateur-source en baisse empêchant l'utilisation des deux autres bases de données peut ne pas être un gros problème qu'il n'y paraît.

De plus, si une base de données tombe en panne maintenant, vous aurez déjà des problèmes de cohérence si les utilisateurs sont modifiés dans les deux autres bases de données au cours de cette période. Je ne pense pas que nous puissions donner les meilleurs conseils sans plus de contexte.

En ce moment, je créerais une quatrième base de données pour les utilisateurs, apporterais des modifications uniquement là-bas et synchroniserais avec les autres bases de données. Vous êtes déjà distribué-dénormalisé en modifiant essentiellement les mêmes données à trois endroits, et vous avez probablement déjà des problèmes de cohérence. Si la tolérance aux pannes est importante, ce schéma donne toujours cela tout en résolvant le problème des entrées multiples.

Je pense qu'avoir cette quatrième base de données uniquement utilisateur / paramètres plutôt que d'utiliser l'une de vos existantes est une bonne stratégie car elle devient moins susceptible de baisser car elle n'est pas liée à d'autres ressources ou fortement utilisée. Je vois maintenant que vous avez dit que vous ne pouvez pas faire cela, mais je ne sais pas pourquoi. Les applications de la base de données principale prennent-elles directement en charge la modification par l'utilisateur, ou la modification par l'utilisateur est-elle une fonction complètement distincte qui peut être indiquée ailleurs?

Certes, avec cette idée de "table d'utilisateurs canonique" - que vous utilisiez des synonymes ou synchronisiez les données - vous ne pouvez pas modifier les utilisateurs pendant une base de données d'utilisateurs en panne, mais cela me semble correct. Résolvez le problème et remontez-le! Une source, un endroit pour éditer, une chose à réparer en cas de panne. Avec la synchronisation, toutes les autres bases de données ont des copies temporaires sur lesquelles elles peuvent travailler, mais pas d'édition. Minimiser la duplication des données entre les systèmes est un objectif formidable et utile. Il est très difficile de saisir les mêmes données à trois endroits, alors faites tout ce que vous pouvez pour éliminer cela.

Pour répondre à plus de vos commentaires, si vos ID utilisateur sont différents dans toutes vos applications, vous devez sérieusement envisager un temps d'arrêt planifié pour vos deux nouvelles bases de données afin de les synchroniser avec la principale (posez une question distincte si vous avez besoin d'idées sur la façon d'accomplir cela, ce qui est délicat mais pas vraiment difficile).

Si vous analysez les besoins de votre entreprise et constatez que la base de données principale doit avoir les données utilisateur correctes, vous les utilisez toujours comme canoniques, puis choisissez entre les synonymes ou la synchronisation pour déterminer comment les temps d'arrêt imprévus affectent toutes les bases de données.

Un autre inconvénient de l'utilisation de synonymes est que vous ne pourrez plus disposer de FK appropriés pour les utilisateurs dans chaque base de données.

ErikE
la source
3

Il manque un "Con"

Lors de la restauration, il est possible que votre utilisateur n'existe pas dans la base de données cible (du synonyme). Disons qu'il est corrompu et que vous devez restaurer à partir d'une sauvegarde.

Autrement dit, l'utilisation de synonymes supposera une intégrité référentielle entre bases de données qui ne peut pas se produire dans la vie réelle.

Une autre conséquence de cela serait des ID utilisateur incompatibles lorsque vous essayez de récupérer à partir de cela. (en ajoutant l'utilisateur après la restauration). Cependant, cela ne devrait jamais être supposé de toute façon en raison de l'intégrité référentielle entre les bases de données que j'ai mentionnée.

Alors ne fais pas ça ...

Une réponse connexe sur dba.se: critères de décision sur le moment d'utiliser un schéma non-dbo par rapport à une nouvelle base de données sur "l'intégrité référentielle entre bases de données" après les restaurations

gbn
la source
Bon point sur la possibilité que la cible n'existe pas, bien que j'essaie toujours de comprendre pourquoi le lien est lié à cette question
Rachel
1
@Rachel: non, la table cible peut exister mais les données peuvent être plus anciennes. Donc, lorsque vous effectuez une restauration, vous avez un utilisateur manquant ... Le lien concerne "l'intégrité référentielle entre les bases de données"
gbn
2

Selon votre plateforme de base de données, une autre option consiste à supprimer les tables des bases de données 2 et 3 et à les remplacer par des vues matérialisées de la table de la base de données 1.

Avantages

  • Maintenance plus facile (des données)
  • Identifiants correspondants
  • Les pannes n'affectent pas les autres bases de données (au moins jusqu'à ce que des modifications doivent être apportées)
  • N'importe quelle base de données peut être utilisée pour récupérer la table.

Les inconvénients

  • Les données ne sont aussi à jour que votre calendrier d'actualisation.
  • Si la définition de la table change, les vues matérialisées peuvent également devoir être modifiées.

Notez également qu'en fonction de la fréquence des recherches, de la fréquence des rafraîchissements et de la fréquence des changements de données, cela peut ou non introduire plus de charge qu'une solution synonyme.

Mise à jour: le commentaire de FrustratedWithFormsDesigner est essentiellement une vue matérialisée pour les plates-formes qui ne peuvent pas faire de vues matérialisées. À l'aide d'un script, les tables pourraient être périodiquement synchronisées. Si une base de données est désignée comme maître, tous les scripts peuvent effectuer leurs modifications en fonction de celle-ci. Cela aurait tous les avantages et les inconvénients d'une vision matérialisée; il ne pouvait tout simplement pas tirer parti des fonctionnalités intégrées.

Leigh Riffel
la source
1
Vous ne pouvez pas matérialiser les vues (vues indexées ici) cross-db dans SQL Server + elles n'ont pas besoin d'être actualisées: elles sont "en temps réel"
gbn
@gbn Mon message a été écrit avant l'ajout de la balise SQL Server.
Leigh Riffel
J'ai ajouté le tag en fonction de votre réponse :)
Rachel
1

Je créerais une 4ème base de données qui stocke les informations utilisateur partagées. Créez Synonymsou Viewsdans chacun des autres Dbs pointant vers la base de données des utilisateurs.

Enfin, je créerais une table d'extension (une table avec une relation un à un avec 'UserDB.Usertable') dans chacun des 3 dbs existants qui contient des données utilisateur spécifiques à cette application.

Modifier: basé sur le commentaire ci-dessous

Dans ce cas, faites en sorte que la première base de données agisse comme table utilisateur principale. Synonymset une table d'extension dans chacun des autres Dbs.

Remarque importante : avec cette approche, si votre première application tombe en panne, les deux autres sont supprimées avec elle! Assurez-vous que tout le monde comprend cet inconvénient.

Crétins
la source
Malheureusement, ce n'est pas une option pour moi. Ce serait mon option préférée si je concevais quelque chose à partir de zéro, mais dans ce cas, je travaille avec un système préexistant. Dans mon cas, nous avions la base de données 1 qui existait depuis de nombreuses années, et avons récemment ajouté les bases de données 2 et 3.
Rachel
Pourquoi peut-on supprimer les tables et pointer le synonyme vers la première base de données mais pas vers une nouvelle?
Désolé, j'ai modifié mon commentaire avant de voir le vôtre. La base de données 1 existe depuis de nombreuses années et est accessible par de nombreuses applications externes. Je ne sais pas quel type de dommage je causerais en supprimant cette table. Les bases de données 2 et 3 sont plus récentes, donc je pense que je peux m'en tirer en supprimant la table Users (et autres tables de paramètres) et en les remplaçant par des synonymes
Rachel
Je vois votre montage ... c'est exactement ce que j'essaie de faire, mais ma question était: est-ce une bonne idée ou non, et sinon, pourquoi?
Rachel
C'est bon. Si vous êtes d'accord pour que les 2 applications d'actualités dépendent entièrement de la première application.