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.