Neuer Primärschlüssel.. Wie anfangen?

[ssoul21]

Hallo Leute,
hab da mal ein Problem. Habe eine kleine Datenbank ( 60 Tabellen ) die als sozusagen Insellösung arbeitet. Also sie wird nur in einer Abteilung verwendet. Nun aber will ich das ein bisschen Ausweiten. Die Datenbank speichert Kundendaten und nähere Informationen zu einzelnen Abwicklungen, dabei ist als Primärschlüssel immer die Kundennummer gesetzt. Diese wird aber von anderen Applikationen nicht verwendet.
Ich habe mir gedacht, dass ich einen zusammengesezten PK erstelle mit folgenden Daten: Kundennummer,Name,Vorname,Geburtsdatum
Würde das gehen, wenn ich nun diese Spalten in alle anderen Relationen mit einfüge, die über die Kundennumer angesprochen werden konnten. Oder sollte nur in einer Tabelle der Primärschlüssel so gewählt werden und anschliessend mit der dortigen ermittelten Kundennumer die anderen angesprochen?

Danke im Voraus und liebe Grüße.

[chapster]

Der Primärschlüssel sollte immer so kurz wie möglich und so lang wie nötig sein.
d.h. wenn die Kundennummer eindeutig ist sollte sie auch der PK sein.

Ist die Kundennummer (aus welchen Gründen auch immer) nicht eindeutig würde ich eine eigene ID für Kunden anlegen, weil ja Kundennummer, Name, Vorname, Geburtsdatum zwar in den allermeisten Fällen eindeutig ist aber eben nicht immer.

[Falk Prüfer]

Hallo,

Der Primärschlüssel sollte immer so kurz wie möglich und so lang wie nötig sein.
d.h. wenn die Kundennummer eindeutig ist sollte sie auch der PK sein.

Ein Primärschlüssel sollte IMMER technischer Natur sein und NICHT aus Nutzdaten bestehen, schon gar nicht aus zusammengesetzten!
Gibt es zusätzliche eindeutige Nutzdaten (z.B. eine Kundennummer), so wird für diese ein ZUSÄTZLICHER eindeutiger Schlüssel (UNIQUE Key) angelegt. Damit vermeidet man riesigen technischen Aufwand falls sich irgendwann die Business-Logik der Nutzdaten ändert.

@ssoul21: Also bitte vergiss das mit dem zusammengesetzten PK aus Kundennummer,Name,Vorname,Geburtsdatum ganz schnell und vermerke dir das ganz fett unter absolutem NoGo.

Gruß Falk

[openshinok]

hallo,
ja aber könnt ihr noch einen Tip zur Insellösung geben?
Habe das Thema aktuell auch....
Es nützt ja nichts wenn er mir die IDs höchzählt und jede Insel bei 1 beginnt. Fasse ich dann die Daten zentral zusammen, kollidieren die doppelten.

[hwoess]

Wenn es darum geht, dass man Daten aus getrennten Datenbanken in eine zusammenführen können muss, dann gibt es meines Wissens zwei Möglichkeiten bezüglich der Primärkeys:
a) jede Datenbank hat eine eigene "Mandantennummer", diese zusammen mit dem IDENTITY-Wert der Tabelle bildet den PK in der gemeinsamen Datenbank.
b) man verwendet GUID's. Die sind garantiert immer eindeutig.

Vorteil bei a): man kennt später in der gemeinsamen Datenbank automatisch, von wem die Datensätze sind, bei der GUID bräuchte man ein zusätzliches Feld dafür.
Vorteil bei b): es kann nicht passieren, dass zwei "Inseldatenbanken" mit der gleichen Mandantennummer arbeiten.

bye,
Helmut

[Bernhard Geyer]

hallo,
ja aber könnt ihr noch einen Tip zur Insellösung geben?
Habe das Thema aktuell auch....
Es nützt ja nichts wenn er mir die IDs höchzählt und jede Insel bei 1 beginnt. Fasse ich dann die Daten zentral zusammen, kollidieren die doppelten.

Wieso überhaupt Datendupletten aufbauen? Ich würde versuchen einen (lesenden) Zugriff auf die Firmenzentrage Kundendatenbank zu bekommen. Und diese dann als führendes System verwenden und nur eigene Daten ergänzen die im Zentralen System nicht gepflegt/vorgesehen sind.

[openshinok]

hallo,
also meine Frage ist separat zu betrachten von der Frage des Threaderstellers. Mir geht es um die Primärschlüssel von Inseldatenbanken die keine Verbindung zur Zentrale haben. Ein Austausch oder Abgleich findet von der Insel zur Zentrale nur Monatlich oder Quartalsweise ohne direkte Verbindung, z.B. per XML-Export oder ähnlich statt.

Meine Ansätze gehe alle in die Richtung a) kombinierter PK aus ID und einem eindeutigen Inselkennzeichen in einem Feld oder b) das gleiche jedoch aufgeteilt in zwei separate Felder und dann PK drüber. Zweiteres stelle ich mir aber für das tägliche Handling in der Zentrale schwieriger vor.