Wie werden Tabellen mit Primärschlüsseln mit automatischer Nummerierung zusammengeführt?

Question

Ich nehme an, jeder läuft dieses Problem hin und wieder: Sie haben zwei Tabellen, die Autonummer Primärschlüssel haben, die zusammengeführt werden müssen. Es gibt viele gute Gründe, warum die Primärschlüssel mit automatischer Nummerierung verwendet werden, um anwendungsgenerierte Schlüssel zu verwenden, aber die Verschmelzung mit anderen Tabellen muss einer der größten Nachteile sein.

Einige auftretende Probleme sind überlappende IDs und nicht synchronisierte Fremdschlüssel. Ich würde gerne Ihre Herangehensweise hören, um dies anzugehen. Ich stoße immer auf Probleme, also bin ich sehr neugierig, ob jemand eine allgemeine Lösung hat.

- EDIT -

Als Antwort auf die Antworten darauf hindeutet, guids oder andere nicht-numerische Tasten zu verwenden, gibt es Situationen, in denen es nur im Voraus eine bessere Idee scheint Autowert Schlüssel zu benutzen (und Sie bereue dies später), oder du übernimmst das Projekt eines anderen oder du erhältst eine ältere Datenbank, mit der du arbeiten musst. Also suche ich wirklich nach einer Lösung, bei der du keine Kontrolle über das Datenbankdesign mehr hast.

Answer 1

Hm, ich bin irgendwie enthusiastisch über die Idee, dass ich AlexKuznetsovs Antwort einfach kommentiert habe, also werde ich eine ganze Antwort darüber machen.

Betrachten Sie die Tabellen mit den Namen table1 und table2, mit id1 und id2 als autonumber Primärschlüssel. Sie werden mit ID3 (einem Primärschlüssel ohne Autonummer) zu Tabelle3 zusammengeführt.

Warum nicht:

1. alle Fremdschlüssel-Constraints zu tabelle1 entfernen und table2
2. Für alle Fremdschlüsselfelder zu tabelle1 Bezug genommen wird, führen Sie eine UPDATE table SET id1 = id1 * 2 und für Felder FK table2 beziehen, führen Sie eine UPDATE table SET id2 = (id2) * 2 + 1
3. Fill table3 durch ein INSERT INTO table3 SELECT id1 * 2 AS id3, ... FROM table1 UNION ALL SELECT id2 * 2 + 1 AS id3 FROM table2
4. erstellen neuer Fremdschlüssel-Constraints Ausführung

Table

Es kann sogar mit 3 oder mehr Tabellen arbeiten, nur mit einem höheren Multiplikator.

Answer 2

Lösungen umfassen:

• Verwenden GUIDs als Primärschlüssel anstelle eines einfacheren Identitätsfeld. Sehr wahrscheinlich, Überschneidungen zu vermeiden, aber GUIDs sind schwieriger zu verwenden und nicht gut mit gruppierten Indizes.

• Machen Sie den Primärschlüssel zu einem mehrspaltigen Schlüssel, wobei die zweite Spalte überlappende Werte auflöst, indem die Quelle der zusammengeführten Daten identifiziert wird. Portable funktioniert besser mit Clustered-Indizes, aber Entwickler hassen mehrspaltige Schlüssel.

• Verwenden Sie natürliche Schlüssel anstelle von Pseudokey.

• Weisen Sie neue Primärschlüsselwerte für eine der zusammengeführten Tabellen zu und kaskadieren Sie diese Änderungen auf alle abhängigen Zeilen. Dies ändert eine Zusammenführungsoperation in eine ETL-Operation. Dies ist die einzige Lösung, die Sie für Legacy-Daten verwenden können, wenn Sie das Datenbankdesign nicht ändern können.

Ich bin mir nicht sicher, dass es eine Einheitslösung gibt. Wählen Sie eine davon basierend auf der Situation.

Answer 3

Eines der Standardansätze (wenn nicht der Standardansatz), wo man für einen solchen Fall sind die Gestaltung, ist eher GUIDs für Primärschlüssel zu verwenden, als ganze Zahlen - Verschmelzen dann relativ schmerzlos ist, wie Sie garantiert nicht einer Überschneidung begegnen.

Abgesehen von einem Redesign, denke ich, dass Sie in die Tabelle einfügen müssen, akzeptieren Sie, dass Sie neue Primärschlüssel erhalten, und stellen Sie sicher, dass Sie die Zuordnung von alt zu neu pflegen. dann fügen Sie referenzierende Daten mit neu zugewiesenem FK usw. hinzu. Wenn Ihre Daten einen "Geschäftsschlüssel" haben, der nach dem Einfügen eindeutig bleibt, würde dies das Nachverfolgen des Mappings ersparen.

Answer 4

Ich bin sicher, dass Sie nur zwei solche Tabellen haben, Sie können nur gerade IDs in einer Tabelle (0,2,4,6, ...) und ungerade IDs in einer anderen (1,3,5,7 , ...)

Answer 5

Angenommen, Sie haben auch einen natürlichen Schlüssel in den zu vereinigenden Tabellen, dann ist der Prozess nicht schwierig. Der natürliche Schlüssel wird verwendet, um Referenzen zu deduplizieren und neu zuzuweisen. Sie können die Ersatzschlüsselwerte jederzeit neu nummerieren - dies ist einer der Hauptvorteile der Verwendung eines Ersatzes an erster Stelle.

So sehe ich das nicht als ein Problem mit Ersatzschlüsseln - vorausgesetzt, Sie erzwingen immer den natürlichen Schlüssel (eigentlich bevorzuge ich den Begriff "Business Key"). Wenn Sie keine Business Keys für diese Tabellen haben, dann ist es vielleicht eine gute Zeit, das Redesign so durchzuführen, dass ALLE notwendigen Schlüssel korrekt implementiert werden.