Zitat:
Ist also eine Auftragsnummer aus Zahlen,Tagesdatum und Bearbeiterkürzel zusammen gesetzt (und natürlich eindeutig) nehme ich sie dennoch nicht als Primärschlüssel.
Das würdest du nur dann nicht tun, wenn dein Datennmodell das verhindert. Dein Beispiel ist ein zusammengesetzter Schlüssel - dessen Teile müssen foreign keys sein oder elementare Datentypen. Wenn du zusätzlich zu diesem Key noch einen weiteren PK einführst, hast du nichts gewonnen und nur Aufwand.
Diese Rechnungsnummer und wie sie aufgebaut ist soll ja nur ein beliebiges Beispiel sein. Jede Firma macht da so ihr Ding, oft sind heterogene Systeme im Einsatz, Quelle/Format der Rechnungsnummer oder irgendeiner anderen Bearbeitungsnummer sind häufig nicht in der (alleinigen) Hoheit der eigenen Anwendung.
Hinzu kommt, dass diese "Welten" nicht statisch sind. Der Tag kommt also, wo dank einer Änderung eines Ablaufs oder dem Austausch einer Software die Dinge plötzlich anders laufen.
Ich sehe das eher so, das die Verwendung natürlicher Schlüssel aus Zeiten stammt, wo Speicherplatz noch kostbar war. Heute liegen die Prioritäten anders, mehr Schnittstellen, mehr Interoperabilität, mehr Flexibilität sind gefordert.
Kleines Beispiel: Kontonummer / BLZ könnte man vielleicht mal als Primärschlüssel verwendet haben. Schwierig wird es schon mit der Bankenkonsolidierung, immer mehr Zweigstellen werden unter einer BLZ zusammengefasst. Dann kommt SEPA und alles ist ganz anders.
Fazit: Je mehr ich die reine Mechanik von fachlicher Funktion trenne, desto besser kann ich ein System auf Änderungen einstellen oder schlicht customizen, wenn ich Stangenwahre anbiete, die der Kunde sich zurecht biegen kann.