Prévention des clés en double entre plusieurs bases de données

Question

Je suis dans une situation où nous avons une nouvelle version de logiciel qui va utiliser une base de données distincte (ancienne modification du schéma). Il y aura une période de temps considérable pendant laquelle le nouveau et l'ancien système seront en production et nous devons nous assurer que des ID uniques sont générés entre les deux bases de données (nous ne voulons pas de ligne dans la base de données A avoir le même identifiant qu'une ligne de la base de données B). Les bases de données sont Sybase.

Solutions possibles que j'ai proposées:

1. Utilisez un type de données qui prend en charge de très grands nombres et attribuez une plage à chacun, en espérant qu'ils ne débordent jamais.
2. Utilisez des valeurs négatives pour une base de données et des valeurs positives pour l'autre.
3. Ajouter une colonne supplémentaire qui identifie la base de données et utilise la combinaison de celle-ci et de l'ID actuel pour servir de clé.
4. Cry.

Que pourrais-je faire d'autre? Existe-t-il des solutions plus élégantes pour que les deux bases de données fonctionnent ensemble? Je crois que les deux bases de données seront sur le même serveur, si cela compte.

Answer 1

J'ai vu cela se produire plusieurs fois. Sur ceux auxquels je suis associé, nous avons simplement alloué un espace d’identification suffisamment grand pour l’ancien (car il fonctionnait depuis un certain temps et nous savions combien de clés il avait utilisées, nous pouvions calculer le nombre de clés supplémentaires. 'besoin d’une "durée de vie" spécifiée) et a lancé le "ID SEQUENCE". de la nouvelle base de données ci-dessus.

Je recommande contre toute autre astuce, ne serait-ce que parce qu'elles nécessitent toutes des modifications de l'application "héritée", ce qui constitue un risque que je ne vois pas la nécessité de prendre.

Answer 2

Les identificateurs globaux uniques ou globaux uniques peuvent être des clés primaires pratiques dans ce type de cas. Je crois que Sybase les soutient.

Éditer: bien que votre base de données entière soit déjà basée sur des clés primaires entières, le passage aux GUID n’est peut-être pas très pratique. Dans ce cas, il suffit de partitionner l’espace entier entre les bases de données, comme suggéré par GWLlosa.

Answer 3

Dans votre cas, j’envisagerais d’utiliser un identifiant unique (GUID) comme type de données. Ils sont considérés comme uniques lorsque vous les créez à l'aide de fonction système newid () .

CREATE TABLE customer (
   cust_key UNIQUEIDENTIFIER NOT NULL
            DEFAULT NEWID( ),
   rep_key VARCHAR(5),
   PRIMARY KEY(cust_key))

Answer 4

Pré-ensemencez votre nouvelle base de données avec un # supérieur à ce que votre ancienne base de données atteindra avant de les fusionner.

Je l'ai fait par le passé et le volume d'enregistrements étant relativement faible, j'ai donc démarré ma nouvelle base de données à 200 000 exemplaires en tant que numéro d'enregistrement initial. puis, le moment venu, j'ai migré tous les anciens enregistrements vers le nouveau système.

a parfaitement fonctionné!

Answer 5

Les GUID sont conçus pour cette situation.

Answer 6

Si vous créez un nombre similaire de nouveaux éléments dans chaque base de données, vous pouvez essayer identificateurs pairs dans une base de données, identificateurs impairs dans l'autre.

Answer 7

Utilisez le type de données UNIQUEIDENTIFIER. Je sais que cela fonctionne sous MS SQL Server et, autant que je puisse en juger d'après Google, Sybase le prend en charge.

http://www.ianywhere.com/developer/product_manuals /sqlanywhere/0902/fr/html/dbrfen9/00000099.htm