Verhindern doppelter Schlüssel zwischen mehreren Datenbanken

Question

Ich bin in einer Situation, in der wir eine neue Version der Software herauskommen haben, die eine separate Datenbank (signifikante Änderungen im Schema) von der alten verwenden wird. Es wird eine beträchtliche Zeit dauern, in der sowohl das neue als auch das alte System in Produktion sein werden und wir müssen sicherstellen, dass eindeutige IDs zwischen den beiden Datenbanken erzeugt werden (wir wollen keine Zeile in der Datenbank A) die gleiche ID wie eine Zeile in der Datenbank B) haben. Die Datenbanken sind Sybase.

Mögliche Lösungen Ich habe kommen mit:

1. einen Datentyp verwenden, die wirklich große Zahlen unterstützt und einen Bereich für jede zuweisen, in der Hoffnung sie nie überlaufen.
2. Verwenden Sie negative Werte für die eine Datenbank und positive Werte für die andere.
3. Hinzufügen einer zusätzlichen Spalte, die die Datenbank identifiziert und die Kombination aus dieser und der aktuellen ID als Schlüssel verwendet.
4. Cry.

Was könnte ich noch tun? Gibt es elegantere Lösungen für die Zusammenarbeit der beiden Datenbanken? Ich glaube, die beiden Datenbanken werden auf demselben Server sein, wenn das wichtig ist.

Answer 1

Ich habe das schon ein paar Mal gesehen. Bei denen, an denen ich beteiligt war, haben wir einfach einen ausreichend großen ID-Platz für den alten zugewiesen (da er schon eine Weile in Betrieb war und wir wussten, wie viele Schlüssel er benutzt hatte, konnten wir berechnen, wie viele Schlüssel er noch hatte benötigt eine bestimmte "Lebensdauer" und startet die "ID SEQUENCE" der darüber liegenden neuen Datenbank.

Ich würde empfehlen, gegen einen der anderen Tricks, nur weil sie alle Änderungen an der "Legacy" -App benötigen, die ein Risiko ist, sehe ich nicht die Notwendigkeit zu nehmen.

Answer 2

GUIDs oder global eindeutige IDs können in diesem Fall nützliche Primärschlüssel sein. Ich glaube, Sybase unterstützt sie.

Edit: Obwohl Ihre gesamte Datenbank bereits auf ganzzahligen Primärschlüsseln basiert, ist der Wechsel zu GUIDs möglicherweise nicht sehr praktisch - in diesem Fall partitionieren Sie den Integerraum zwischen den Datenbanken, wie GWLlosa und andere vorgeschlagen haben.

Answer 3

Setzen Sie Ihre neue Datenbank mit einem # vor, das größer ist als das, was Ihre alte Datenbank erreicht, bevor Sie sie zusammenführen.

Ich habe dies in der Vergangenheit getan und die Menge der Datensätze war einigermaßen niedrig, so dass ich meine neue Datenbank bei 200.000 als die erste Datensatznummer gestartet. Als die Zeit gekommen war, habe ich einfach alle alten Aufzeichnungen in das neue System migriert.

Ausgezeichnet ausgearbeitet!

Answer 4

GUIDs sind für diese Situation ausgelegt.

Answer 5

In Ihrem Fall würde ich UniqueIdentifier (GUIDs) als Datentyp verwenden. Sie gelten als eindeutig, wenn Sie sie mit der system function newid() erstellen.

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

Answer 6

Verwenden Sie den Datentyp UNIQUEIDENTIFIER. Ich weiß, dass es in MS SQL Server funktioniert und soweit ich das von Google sehe, unterstützt Sybase es.

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

Answer 7

Wenn Sie auf jede Datenbank eine ähnliche Anzahl von neuen Produkten erstellt werden soll, können Sie sogar ids auf einer Datenbank, ungerade ids im anderen versuchen.