Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: zusammengesetzter Primary Key mit Deleted-Flag

Re: zusammengesetzter Primary Key mit Deleted-Flag

From: Immo Landwerth <mail_ignored_at_web.de>
Date: 2 Oct 2003 16:31:13 GMT
Message-ID: <blhjsh$ccpa8$1@ID-169341.news.uni-berlin.de>


Marian Aldenhoevel wrote:

> Hallo,
>
> > Was immer der Fall sein sollte, da man in nahezu allen Fällen
> > zweifeln muss... :)
>
> Es gibt schon typische PK-geeignete "echte" Datenfelder. Jedenfalls
> was die Eindeutigkeit innerhalb der Tabelle angeht. Zum Beispiel
> Ausweis- oder Matrikelnummern. Bestellnummern innerhalb eines
> Katalogs, Rechnungsnummern et al..

Das Problem liegt häufig nicht in der Eindeutigkeit des Feldes selbst, sondern im Datenmodel begründet. Der Kunde möchte z.B. plötzlich auch ausländische Personen erfassen, die eine andere Ausweisnummer haben und wofür das Feld "AUSWEISNUMMER" leerzulassen ist. PK Felder dürfen bekanntermaßen aber nicht NULL sein.

> - Jeder Datensatz muss eines davon haben. Mit Matrikelnummern als
> PK kann man nur Studenten erfassen.

Bingo. S.o.

> - Das Merkmal sollte sich möglichst während der ganzen Lebensdauer
> eines Datensatzes nie mehr ändern.

Bei einigen Datenbanken kann man sogar von "sollte sich möglichst" durch "darf/kann sich nicht" ersetzen.

Die Probleme, die eine Änderung des PK mit sich bringen sind so groß, dass ich dem erhöhten Initialaufwand durch generierte PKs lieber Rechnung trage, als eine Änderung von vorhandenen (Detail-) Datensätzen.

> Weil die letzte Anforderung ein typischer Kandidat für eine
> Aufweichung während der Entwicklungsgeschichte der
> Datenbank/Anwendung ist, neige ich aber auch dazu, einfach mal
> prophylaktisch jedem Datensatz eine Nummer mitzugeben, die mit der
> richtigen Welt nichts zu tun hat und nur innerhalb der Datenbank
> Verwendung findet.

Ja, genauso meinte ich das: Auch wenn man wirklich zu wissen glaubt, dass Feld XY eindeutig ist, sollte man deennoch nur einen UNIQUE INDEX drauflegen und einen generierten (künsltichen) Wert als PK verwenden. Dieses Feld ist im Frontend nicht sichtbar, was die Wahrscheinlichkeit, dass der Kunde in diesem Berich Änderungen wünscht, gegen 0 gehen lässt.

Fazit: Wann immer es geht, nur generierte Felder als PK verwenden.

-- 
Immo Landwerth - XP Pro SP1 - D5 Pro UP 1 - XanaNews 1.15.7.2
Received on Thu Oct 02 2003 - 11:31:13 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US