2010-03-18 1 views
16

Gibt es Auswirkungen auf negative Primärschlüssel für Tabellen (Identity Increment -1, Identity Seed -1 in SQL Server 2005)?Negative Primärschlüssel

Der Grund dafür ist, dass wir eine neue Datenbank erstellen, um eine vorhandene zu ersetzen. Es gibt ähnliche Tabellen zwischen den beiden Datenbanken und wir möchten, dass die "Quelle" der Informationen für unsere Anwendungen transparent ist. Der Ansatz besteht darin, Ansichten zu erstellen, die Tabellen aus beiden Datenbanken zusammenführen. Negative PKs gewährleisten, dass sich die Identitäten nicht überschneiden.

+3

Erwägen Sie, die Daten aus der alten Datenbank in die neue Datenbank zu importieren (neue PK-Werte erstellen), anstatt die alten Tabellen beizubehalten und Ansichten zu erstellen. Die Leistung wird besser sein und Sie werden in Zukunft weniger Komplexität haben. –

+0

Das wäre ideal, aber die Lichter müssen in den Legacy-Anwendungen und der DB verbleiben, bis die Plattform neu ist. In der Zwischenzeit müssen neue Apps auf Informationen von beiden Standorten zugreifen. – bjaxbjax

+0

Ich denke, 2 Quellen zu haben ist nicht der richtige Grund für diesen Ansatz, obwohl technisch erlaubt. Es ist nicht skalierbar. – Tengiz

Antwort

14

Wie andere gesagt haben, ist die Datenbank in Ordnung.

Aber es wäre ein Problem für eine .NET-Anwendung, die DataSet + DataAdapter verwendet, da sie negative Schlüssel als Provisorien für neue Datensätze verwenden.

Andere Datenzugriffsebenen können ähnliche Tricks verwenden.

+0

Danke für die Köpfe hoch Henk. Wir verwenden für den Moment eine angepasste Datenzugriffsebene, werden aber in Situationen wie dieser nach vorne schauen. – bjaxbjax

+1

Beachten Sie jedoch, dass ein INSERT keine einfache Append-Operation mehr ist, wenn Sie Ihren Primärschlüssel als Clustered-Index haben. – erikkallen

2

Kein Problem.

Es ist etwas unorthodox, aber abgesehen davon gut.

Der Standard von SQL Server ist nur das - ein Standard und kann geändert werden, um Bedürfnisse anzupassen. Sieht so aus, als hättest du einen guten Kompromiss gefunden.

7

Dies ist aus SQL Server-Perspektive völlig in Ordnung. Die eigentliche Frage wird Ihre Bewerbung sein.

3

Das einzige Problem ist, dass Sie auf diese Weise keine dritte Datenquelle hinzufügen können!

+17

Es sei denn, sie beginnen mit imaginären Zahlen ... Dann könnten sie Tasten haben wie 1 + 2 * i * – FrustratedWithFormsDesigner

0

Es ist kein Problem. Stellen Sie nur sicher, dass Ihre Identity-Spalte von einem Typ ist, der negative Zahlen zulässt.

5

Sie sollten Legacy-Code überprüfen und nach Entwicklern suchen, die nach dem Primärschlüssel sortiert sind, um nach Datum zu sortieren (da Identitätspk normalerweise stark oder perfekt mit der Zeit korreliert sind).

1

Wenn negative Zahlen zu einem Bruch führen, verwenden Sie gerade Zahlen für die eine und ungerade Zahlen für die andere.

0

Eine andere Option besteht darin, den Legacyschlüsseln eine Zeichenfolge wie "OLD_" voran zu stellen. Das einzige Problem ist, dass Ihr Schlüsselfeld nicht numerisch ist.

Wenn Sie numerische Schlüssel haben müssen, könnten Sie eine "alte" Indikatorspalte einführen, und der Primärschlüssel wäre eine Kombination aus der numerischen ID und dem Legacy-Indikator (hoffentlich sollte diese Kombination eindeutig sein).

0

Ich denke, 2 Quellen ist nicht der richtige Grund für diesen Ansatz, während technisch erlaubt. Es ist nicht skalierbar (+1 zu Larry Lustigs Antwort dafür).

Ich würde nur eine Ansicht oder eine gespeicherte Prozedur erstellen, die beide Daten kombiniert, indem die IDs nach Bedarf konvertiert, und hätte Anwendung, um es anstelle direkter Tabelle liest und Unions zu verwenden. Dies wäre skalierbar, indem die Ansicht/SP später geändert wird, um eine weitere Quelle hinzuzufügen.