Primarykeys über mehrere Standorte hinweg

[norwegen60]

Hallo zusammen,

ich habe eine Anwendungen, die unter folgenden Bedingungen laufen soll:

Prüfschränke sollen innerhalb einer Fa. auch dann laufen, wenn das Netz (der Server) nicht verfügbar ist. Die Grunddaten (Prüfpläne, Serien-Nr., ... werden aber immer auf dem Server behandelt. Nur Prüfprotokolle müssen noch lokal weiter erstellbar sein. Derzeit überlege ich noch, ob ich mit Replikationen arbeiten soll oder andere Wege suchen soll.

Lösungsansatz: Der Primarykey für die Protokolldaten setzt sich aus einer ID + dem Prüfplatz-ID zusammen

Grunddaten sollen zwischen verschiedenen Standorten ausgetauscht werden. Die Daten sind eindeutig, d.h. z.B. User können pro Standort eigenständig verwaltet werden. Die Daten anderer Standorte sollen aber am Stammsitz zusammengezogen werden können
Lösungsansatz 1: Definition von Nummernbändern, z.B Standort 1 ab 1, Standort 2 = ab 5'000'000, ...
Lösungsansatz 2: Zusammengesetzter Primarykey aus ID + Standortkennung. Ist schon als char(1) vorhanden
Lösungsansatz 3: Unique keys

Gegen L2 spricht, dass pro Detailsatz 2 Felder notwendig sind
Gegen L3 spricht, dass ein sprachlicher Informationsaustausch per ID unmöglich ist e357c628-148f-4cd6-9ca5-d28a8355c7c4 kann sich keiner auch nur kurzfristig merken, 5'000'112 schon.

Von daher bervorzuge ich L1 zumal 5'000'000 Stellen ca 150 Jahre pro Standort halten.

Zum einen würde ich mich über den ein oder anderen Kommentar zu den Lösungsansätzen freuen. Hauptsächlich aber wüsste ich gerne zwei Sachen:

1. Was passiert am Hauptsitz, wenn dort ein Datensatz mit der ID 5'000'393 eingespielt wird obwohl dort nur ID's 1..4'999'999 vergeben werden. Werden dann dort ID's ab 5'000'393 vergeben?
2. Gibt es in MsSQl eine Möglichkeit, die DB lokal so zu installieren, dass für alle Tabellen gilt: ID-Startwert = 5'000'000. Derzeit wird die DB als Restore einer Leertabelle erzeugt.

Vielen Dank
Gerd

[Sir Rufo]

Zum Replizieren (mit dem Replizierungsmechanismus von MSSQL) muss man AFAIK mit GUIDs arbeiten.

Somit würde sich für diesen Einsatz eine Kombination aus 2 Schlüsseln anbieten.

Code:

ReplId : GUID
PlatzId : int
ProtID : int

PrimaryKey( ReplId )
UniqueIndex( PlatzId, ProtId )

Jeder Arbeitsplatz (Protokollplatz) sollte sich vorher am Server anmelden und eine entsprechende Id anfordern, damit diese pro Platz auch eindeutig ist.
Jetzt kann jeder Platz soviele Protokolle speichern, bis ProtId überläuft

[Hansa]

Lösungsansatz 1 ist ja auch nicht nur am Einfachsten, sondern stelle dir mal folgendes vor : es heisst, "nie und nimmer kommen Daten aus diesem Standort in die DB !." Wetten, dass das doch irgendwann gemacht werden soll ? Es wären dann doppelte IDs da. Hättest Du trotzdem auch für die Nie und Nimmer - Filiale, einen eigenen Nummernkreis gemacht, dan wären das Peanuts.