sprechender Primärschlüssel 8)

[Hansa]

Das hier ist Mabuses Schuld. Aber es interessiert mich, ob so was immer noch Gang und Gäbe ist. Also : wie siehts aus, ohne ID ? Wer macht so was ? Ich kann ja noch verstehen, wenn einer bei Textilien eine "sprechende Art.-Nr." verwendet. Aber beim Primary Key hörts doch wohl auf. 8)

[WoGe]

Hallo,

niemals ohne ID, hatte ich hier auch schon mal gesagt.
Unter gewissen Bedingungen, wie z.B. nur ein Messgerät könnte man noch einen Timestamp akzeptieren. Aber wie ich aus praktischer Erfahrung gelernt habe ist auch das schon fragwürdig.

mfg
wo

[r_kerber]

Ich kenne ein System, da war der PK ein zusammengesetzter Schlüssel, teilweise sogar mit VARCHAR-Spalten. War zwar sehr sprechend, IMHO aber auch eine Performance-Bremse.

[MaBuSE]

Zitat von Hansa:

Das hier ist Mabuses Schuld.

Danke

Ich kenne mehrere Systeme die sprechende Primärschlüssel haben.

Das Beispiel mit den Datum habe ich ja schon gepostet.
Das "Datenmodel" war schon "fertig" als wir in das Projekt einstiegen.
Leider gab es keine Möglichkeit das wieder geradezubiegen.
Das Projekt hatte über 300 Tabellen davon waren über 80 mit diesem sprechenden Schlüssel.

Wenn ein Termin verschoben wurde, musste in allen 80 Tabellen der Schlüssel geändert werden.

Da das ganze anfangs auf der BDE mit Paradox Dateien aufbaute und erst später nach Sybase SQL Server und danach auf MS-SQL Server portiert.
auf dem SQL Server gab es wenigstens die Möglichkeit das Ganze in eine StoredProc zu packen.

(Fast alle PKs waren sprechende Schlüssel, aber dieser war besonders schlimm!)

Anderes Beispiel:

In einer Anwendung zum Wertpapiergeschäft gab es einen sprechenden Schlüssel mit der WKN.
Es hatte niemand damit gerechnet, das die WKN (Wertpapiernummer) durch die ISIN abgelöst wurde.
So mussten die ganzen Schlüsselfelder erweitert werden um die längere ISIN aufzunehmen. Außerdem mussten neue Felder mit der "alten WKN" angelegt werden.
Ich hätte lieber gleich eine fortlaufende Nummer als Primärindex genommen und die ISIN und WKN als Matchcode in 2 weitere Felder abgelegt.

Die zu verwaltenden Fonds waren natürlich auch als sprechende Schlüssel angelegt
(so konnte man direkt ohne Verknüpfung mit anderen Tabellen select Statements ausführten, die den Fonds oder die WKN selektierten. Das war die offizielle Begründung)

Ich könnte noch einige Beispiele mehr nennen, (unter anderem auch in Fachkreisen bekannte Programme) die solche sprechenden Schlüssel haben

Ach ja, die Programme sind immer noch im Produktiven Einsatz, auch wenn ich Sie (zum Glück) nicht mehr betreue.

[Jasocul]

Ich benutze grundsätzlich eine ID als PK. Auch bei Tabellen, wo man davon ausgehen sollte, dass es nicht erforderlich ist. Wie man Mabuses Beitrag sieht, ist das durchaus sinnvoll.

Aber wenn man Altlasten übernehmen muss, ist man halt in den A... gekniffen.

P.S.: Warum steht das unter K&T? Gehört das nicht in Datenbanken?

[MaBuSE]

Zitat von Jasocul:

Ich benutze grundsätzlich eine ID als PK.

Meinst Du mit ID einen Integer oder eine GUID

Ich habe auch schon mit Systemen gearbeitet in denen alle Primärschlüssel so aussahen:

Code:

c2755174-b4f7-4662-85b2-8579c851d48b

Also eine GUID.
Da diese weltweit einmalig ist, kann man relativ leicht Syncronisationen von mehreren dezentral laufenden SQL Servern durchführen. Die PKs sind ja weltweit einmalig, also können Datensätze einfach "hinzukopiert" werden.
Zu jedem Datensatz wird noch eine Timestamp gespeichert, dann kann man mit

SQL-Code:

insert into TABELLE from
select * from TABELLE@REMOTEHOST
where TIMESTAMP_FIELD > :TIMSTAMP_OF_LAST_SYNC

einen Abgleich starten.

Dumm nur, das eine GUID im VARCHAR2 oder CHAR nicht so performant ist wie ein Integer

[edit]
Das macht aber auch z.B. Sinn wenn die Clients auch offline Daten erfassen können, die dann erst mal lokal gespeichert werden und später mit dem Server syncronisiert werden.
[/edit]

[ibp]

sicherlich ist es sinnvoll entititäten zu benutzen. je nach situation spricht imho nichts gegen einen mnemonischen schlüssel. oder?

[Hansa]

@Daniel :

Zitat von MaBuSE:

c2755174-b4f7-4662-85b2-8579c851d48b

Das wurde in Zitat Funktion nicht aufgeführt. Nur zur Info

Zum Thema :

Zitat von MaBuSE:

c2755174-b4f7-4662-85b2-8579c851d48b

Der Thread gibt doch was her. Ist tatsächlich einer auf die Idee gekommen, so einen string-PK zu benutzen ? Wer war das ? Sind die Programme uralt von Lochkarten, oder was ?

[Jasocul]

@MaBuSE:
Es sind Integer-IDs.

An GUID hatte ich bisher nicht gedacht. Da müsste man dann allerdings abwägen, ob man den Performance-Verlust zu Gunsten der Funktionalität (weltweiter Abgleich, Offline-Erfassung), akzeptieren kann.