Zusammengesetzter Primärschlüssel
Holger Janßen
ich habe eine Tabelle, wo es sich anbieten würde einen zusammengesetzten
Primärschlüsel zu nutzen. Allerdings gibt es da noch eine zusätzliche
Tabelle, die in Abhängigkeit zu dieser Tabelle steht. Müssen für den
Fremdschlüssel dann auch 2 Felder eingerichtet werden? Wenn ja, kann ich
ja doch besser ein zusätzliches Feld mit AutoWert einfügen, der der
Primärschlüssel ist, oder?
Mark Doerbandt
Holger Janßen:
Das kommt darauf an! ;-) Erzaehl doch mal, warum Dein
Primaerschluessel zusammengesetzt ein guter ist. Wenn er das wirklich
ist, musst Du eben zwei Felder in der Beziehung nutzen, wenn nicht,
die ID.
Gruss - Mark
--
Informationen fuer Neulinge in den Access-Newsgroups unter
http://www.doerbandt.de/Access/Newbie.htm
Bitte keine eMails auf Newsgroup-Beiträge senden.
Gernot Adams
"Holger Janßen" <e...@fd-domo.de> schrieb im Newsbeitrag
news:42BA8C7B...@fd-domo.de...
lege einen Unique-Index über die beiden Felder und verwende als
Primärschlüssel ein Autowertfeld.
Gruß
Gernot
Antje Kaiser
also, warum nicht ein zusammengesetzter Primärschlüssel? Falsch ist es auf
jeden Fall nicht. Nachteil ist nur, wie Du schon selbst sagst, daß ein
solcher als Fremdschlüssel immer länger wird. Z.B. wenn Deine abhängige
Tabelle dann vielleicht durchaus einen sinnvollen dreifachen Primärschlüssel
bekommen könnte, eben durch den doppelten Fremdschlüssel. Ich denke am Ende
ist es eine Abwägung. Ich mach es so: Grundlegende, wichtige, hin und wieder
ganz konkret zu benennende Dinge wie Personen oder Gebäude oder Bücher oder
auch ganz konkrete Vorgänge (die ja meistens aus m:n Beziehungen entstehen)
identifiziere ich durch einfache ID's, andere nicht ganz "im Mittelpunkt"
stehende Tabellen können ruhig auch mal mehrspaltige Schlüssel haben (ein
Maximum würde ich aber bei drei Spalten setzen). Wichtig bei der Überlegung
ist sicher auch, ob zu erwarten ist das die Tabelle noch weiter referenziert
werden muß im DB-Modell. Wenn man sicher ist da kommt nichts mehr, geht
ausnahmsweise vielleicht auch mal ein Dreierschlüssel, aber wenn zu sehen
ist, das das DB-Modell an der Stelle noch wachsen kann, dann würd ichs lieber
lassen.
Soviel zu meiner Philosophie zu diesem Thema :-)
--
Gruß
Antje
"Holger Janßen" schrieb:
Michael Zimmermann
Antje Kaiser:
> also, warum nicht ein zusammengesetzter Primärschlüssel?
> Falsch ist es auf jeden Fall nicht.
Nein, das ist er nicht.
> Nachteil ist nur, wie Du schon selbst sagst, daß ein
> solcher als Fremdschlüssel immer länger wird.
Es gibt noch mehr Nachteile:
Mehrfelderschlüssel sind meist assoziativ, also nicht nur
mehrfach, sondern auch sinntragend. Das bedeutet, sie werden
zum einen vom Benutzer eingegeben und zum anderen könnten
sie sich ändern. Beides - vor allem die Benutzereingabe -
sind potentielle Fehlerquellen. Ein referentieller Schlüssel
wird vom System generiert (AutoWert), was außer bei Access,
dem allzu menschlichen, garantiert fehlerfrei ist.
Joins über mehrere Felder sind langsamer als Joins über
ein Feld.
Es gibt aber auch Vorteile:
Wenn z. B. speziell die Schlüsselfelder als Information
häufig gebraucht werden, die davon abhängigen Daten aber
sehr selten, dann führt der Mehrfelderschlüssel dazu, daß
viele Abfragen keinen Join benötigen, da die Informationen
als Fremdschlüssel schon vorliegen. Das kann deutliche
Performance-Vorteile bieten.
> ... Ich mach es so: Grundlegende, wichtige, hin und wieder
> ganz konkret zu benennende Dinge wie Personen oder
> Gebäude oder Bücher...
... harte Entitäten oder Stammdaten...
> ... identifiziere ich durch einfache ID's,
Das ist vernünftig, da es hier oft gar keine eindeutige
Feldkombination gibt.
> oder auch ganz konkrete Vorgänge (die ja meistens aus
> m:n Beziehungen entstehen) identifiziere ich durch
> einfache ID's,
Vorgänge sind per definitionem nicht konkret, sonst wären
sie ja Dinge und keine Vorgänge. ;-)
Gerade in m:n-Beziehungen bietet sich im Gegenteil oft
das Fremdschlüsselpaar als Primärschlüssel an. Ein
zusätzlicher Parallelschlüssel ist zwar unschädlich,
aber oft auch unnütz.
> ... andere nicht ganz "im Mittelpunkt" stehende Tabellen
> können ruhig auch mal mehrspaltige Schlüssel haben...
M. E. kein schönes Kriterium. Ich würde die Entscheidung
nach rein strukturellen Erwägungen treffen.
> (ein Maximum würde ich aber bei drei Spalten setzen).
Für den seltenen Fall einer echten, nicht auflösbaren
Beziehung zwischen 12 Objekten muß ein eindeutiger Index
über die 12 Fremdschlüssel sowieso angelegt werden.
Falls nicht weiter referenziert wird, kann er auch gleich
PS sein.
> Wichtig bei der Überlegung ist sicher auch, ob zu erwarten
> ist das die Tabelle noch weiter referenziert werden muß im
> DB-Modell. Wenn man sicher ist da kommt nichts mehr, ...
Es kann auch genau das Gegenteil eintreten, siehe z. B.
> Soviel zu meiner Philosophie zu diesem Thema :-)
... der man in weiten Teilen zustimmen kann. ;-)
Gruß aus Mainz
Michael