Nous avons trois bases de données physiquement séparées par région, une à LA, SF et NY. Toutes les bases de données partagent le même schéma, mais contiennent des données spécifiques à leur région. Nous cherchons à fusionner ces bases de données en un et à la miroir. Nous devons préserver les données de chaque région, mais les fusionner dans une DB. Cela présente quelques problèmes pour nous, par exemple, nous aurons certainement des clés primaires en double et des clés étrangères seront potentiellement invalides.
J'espère trouver quelqu'un qui a eu de l'expérience avec une tâche comme celle-ci qui pourrait fournir des conseils, des stratégies et des mots d'expérience sur la manière dont nous pouvons accomplir la fusion.
Par exemple, une idée était de créer des touches composites, puis de modifier notre code et des Sprates pour trouver les données via la touche composite (région / pk d'origine). Mais cela nous oblige à changer de tous nos Code et Sprates.
Une autre idée était de simplement importer les données et de la laisser générer de nouveaux PK puis mettez à jour toutes les références FK à la nouvelle PK. De cette façon, nous n'avons potentiellement pas à changer de code.
Une expérience est la bienvenue!
6 Réponses :
Une chose que vous pourriez faire est de mettre en place les tables avec des données régionales pour utiliser GUID. De cette façon, les clés primaires de chaque région sont uniques et vous pouvez mélanger et faire correspondre des données (données d'importation d'une région à une autre). Pour les tables qui ont partagé des données (comme tables de type), vous pouvez conserver les touches primaires comme elles sont (car elles doivent être les mêmes partout).
Voici quelques informations sur GUID: http://www.sqlteam.com/article/uniqueIdidentifIfultifier-vs-Identity
Peut-être que SQL Server Management Studio vous permet de convertir des colonnes à utiliser facilement GUID. J'espère!
meilleure des chances.
Je n'ai aucune expérience de première main avec cela, mais il me semble que vous devriez être capable de créer de manière unique PK -> Nouveau PK pour chaque serveur. Par exemple, générer de nouvelles PKS telles que les données de La Server a pk% 3 == 2, SF a pk% 3 == 1 et NY a pk% 3 == 0. Et depuis que j'ai bien compris votre question, chacun Server uniquement stocke les relations FK à ses propres données, vous pouvez mettre à jour les FKS en mode identique.
NewLA = OldLA*3-1 NewSF = OldLA*3-2 NewNY = OldLA*3
meilleur: strong> Ajoutez une colonne pour la catégorieCode, et incluez-la sur vos PKS, mais vous ne voulez pas faire tout le travail de la jambe. hack: strong> Si vos identifiants sont des INTS, une solution rapide serait d'ajouter une valeur fixe basée sur la région à chaque touche d'importation. Les INT peuvent être aussi importants que: 2,147 483,647 p> Données du serveur local: P> LA IDs: 100000001,100000002,100000003,100000004,100000005,100000006
SF IDs: 200000001,200000002,200000003,200000004,200000005
NY IDs: 300000001,300000002,300000003,300000004,300000005,300000006,300000007,300000009
Qu'est-ce que j'ai fait dans une situation comme celle-ci est la suivante:
Comme Jon mentionné, j'utiliserais des GUDS pour résoudre la tâche de fusion. Et je vois deux solutions différentes qui nécessitaient des GUID:
C'est une bonne solution en général, mais si Vous avez beaucoup de code non SQL qui est en quelque sorte lié à la manière dont vos identifiants fonctionnent, cela pourrait nécessiter des changements de code assez. Probablement depuis que vous fusionnez des bases de données, vous pouvez quand même vous permettre de mettre à jour votre application afin qu'il fonctionne avec une seule région de région uniquement sur la base de l'utilisateur connecté, etc. em> p> Celui-ci est un peu plus délicat, mais une fois que vous avez écrit ce script de migration, vous pouvez l'exécuter plusieurs fois pour fusionner des bases de données au cas où vous le feriez la vêtir la première fois. Voici un exemple: p>
blockQuote> Vos scripts alters sont (Notez que pour tous les PK, nous générons automatiquement le GUID): p> alors que vous mettez à jour Les FKS doivent être compatibles avec des entiers: p> Vous faites ceci pour tous les PKS (générez automatiquement GUID) et FKS (mise à jour comme indiqué ci-dessus). P> Maintenant, vous créez votre base de données cible. Dans cette base de données cible, vous ajoutez également les colonnes UID pour tous les PKS et FKS. Désactivez également toutes les contraintes FK. P> Vous insérez maintenant à partir de chacune de vos bases de données source à la cible One (Remarque: nous ne insérons pas PKS et Integer FKS): P> 2) ajoutez temporairement GUIDS des fins de migration uniquement et une fois que les données sont migrées, déposez-les: H2>
--// set ADDRESS.PERSON_ID
UPDATE ADDRESS
SET ADDRESS.PERSON_ID = PERSON.ID
FROM ADDRESS
INNER JOIN PERSON
ON ADDRESS.PERSON_UID = PERSON.UID
Fondamentalement, le plus gros problème est que les relations entre les tables et le flux de travail dans la réponse montre comment le résoudre. Bonne chance!
J'ai fait cela et je dis changer vos clés (choisir une méthode) plutôt que de changer votre code. Invariablement, vous manquez une procédure stockée ou introduisez un bug. Avec des modifications de données, il est assez facile d'écrire des tests pour rechercher des enregistrements orphelins ou pour vérifier que les choses ont été adaptées correctement. Avec des changements de code, en particulier le code qui fonctionne correctement, il est trop facile de manquer quelque chose.
Je n'ai aucune solution, mais ceci est un excellent exemple quand il est une bonne chose à avoir des GUIDS / des informations créatifs comme des clés primaires. ;)
Certainement d'accord Simon! Malheureusement, ce modèle de DB était en place bien avant de commencer à travailler sur ce projet. Une machine temporelle serait certainement utile! :)