primary key - id oder String

A

-AbeAdapti-

Mitglied
Hi,
ich stehe öfters vor der Frage wenn ich eine neue Tabellenstruktur anlege, was ich als primary key nehmen soll.
In der Uni hab ich noch gelernt Strings zu einem PK zusammenzufassen zB. username + abteilung (hat halt auch den Vorteil, keine Uniques zu brauchen). In der Realität ist mir das aber so noch nicht begegnet, dort wird meist eine incrementelle id bevorzugt.

Was ist das für und wieder & Warum sollte man eine bestimmte lsg bevorzugen. (z.B. aus Performance, Wartungs oder Architekturgründen). Mir ist es prinzipiell egal, solange die Db die großen PKs mitmacht (MSSQL 2000 z.b. riegelt bei 900byte ab ;)
 
-AbeAdapti- hat gesagt.:
Hi,
ich stehe öfters vor der Frage wenn ich eine neue Tabellenstruktur anlege, was ich als primary key nehmen soll.
In der Uni hab ich noch gelernt Strings zu einem PK zusammenzufassen zB. username + abteilung (hat halt auch den Vorteil, keine Uniques zu brauchen). In der Realität ist mir das aber so noch nicht begegnet, dort wird meist eine incrementelle id bevorzugt.

Was ist das für und wieder & Warum sollte man eine bestimmte lsg bevorzugen. (z.B. aus Performance, Wartungs oder Architekturgründen). Mir ist es prinzipiell egal, solange die Db die großen PKs mitmacht (MSSQL 2000 z.b. riegelt bei 900byte ab ;)
Zum Vergrößern anklicken....

- Hmmm... Ich persönlich ziehe ID's vor, aber von Fall zu Fall kann ein zusammengesetzter Schlüssel auch Sinn machen. ID's habe aber einige Vorteile :

- sie sind "einfacher zu finden", d.h es ist manchmal nicht so einfach, einen "echten" PrimaryKey zu finden (Dein Beispiel mit dem Username zeigt es...der Username "KANN" ändern..)
(BTW, was meinst du mit :::: (hat halt auch den Vorteil, keine Uniques zu brauchen). :::?

- sie sind vom Platzbedarf optimaler (Falls viele FK's verwendet werden z.b)
- sie laufen nicht Gefahr, dass jemand das Bedürfnis verspürt, den PK zu ändern..


Gruss
 
Vorteil String:
BTW, was meinst du mit :::: (hat halt auch den Vorteil, keine Uniques zu brauchen)
Zum Vergrößern anklicken....
Wenn du als PK die id nimmst muss der username+abteilungg z.B. unique bleiben, d.h. ein weiterer Index muss in der Db mitgeführt werden, von der Sortierung ganz zu schweigen.


Vorteil Id:
sie sind vom Platzbedarf optimaler (Falls viele FK's verwendet werden z.b)
Zum Vergrößern anklicken....
Stimmt bei Joins sind ids schneller, da sie weniger Platz im Speicher benötigen als ein zusammengesetzter Schlüssel


Nachteil id:
Die Id ist in den seltesten Fällen das Such bzw. Sortierkriterium, d.h. man muss mit mehr Indexen arbeiten.
sie laufen nicht Gefahr, dass jemand das Bedürfnis verspürt, den PK zu ändern..
Zum Vergrößern anklicken....
nun wenn jemand versuch den PK zu änderen ist das bei StringPKs schwieriger als bei einer Id, da die Id nie geändert wird bei solchen modellen. StringPKs werden konsequent immer durchgezogen, laufen dafür aber gefahr sehr lang zu werden, nach jedem x ten FK verknüpfung


Irgendwo fehlt mir noch der ausschlaggebende Grund warum eine Lsg zu bevorzugen ist, vielleicht arbeiten wir mit Ids nur aus reiner Faulheit, weil sie scheinbar einfacher sind ;)
 
-AbeAdapti- hat gesagt.:
Irgendwo fehlt mir noch der ausschlaggebende Grund warum eine Lsg zu bevorzugen ist, vielleicht arbeiten wir mit Ids nur aus reiner Faulheit, weil sie scheinbar einfacher sind ;)
Zum Vergrößern anklicken....

Ich glaube, dass ist der Hauptgrund. Außerdem hast du bei einem zusammengesetzen Schlüssel aus Strings immer die Möglichkeit, dass doch mal einer doppelt ist und dass DBMS anfängt zu weinen :-) bzw. der User vor einem Problem steht.
Nimmst du eine ID (automaitsch über autowert, Sequenz..), bist du immer auf der sicheren Seite. Ansonsten müsstes du noch viel mehr auf Anwendungsebene abprüfen.
 
Vielleicht ist das nicht der einzige Grund, das wissen über zusammengesetzte PKs ist bei mir noch recht jung. Bedenke man das MSSQL2000 nur zu 900Bytes PKs fähig ist, dann waren Ids vielleicht früher die einzige Chance, verkettungen über mehr als 4 Tabellen hinzukriegen.


Ich glaube, dass ist der Hauptgrund. Außerdem hast du bei einem zusammengesetzen Schlüssel aus Strings immer die Möglichkeit, dass doch mal einer doppelt ist und dass DBMS anfängt zu weinen bzw. der User vor einem Problem steht.
Nimmst du eine ID (automaitsch über autowert, Sequenz..), bist du immer auf der sicheren Seite. Ansonsten müsstes du noch viel mehr auf Anwendungsebene abprüfen.
Zum Vergrößern anklicken....
Aber es spricht doch für zusam. PKs das User keinen blödsinn in die DB schreiben, man sollte so oder so nichts in einer Db ändern wenn man keine Ahnung von dessen Struktur hat bzw. wenn die Db verweigert, dann wird das seinen Grund haben.

BTW: kennt jemand eine gute Literatur darüber (also keine abgedrehte Referenz, mehr so eine best practise sammlung)
 
Hab vielleicht eine zufriedenstellende Antwort gefunden.

Im Prinzip sind zusammengesetzte Schlüssel schon als PK geeignet, solange sie nicht gegen das Prinzip der Minimalität verstoßen, bei dem man aus geht das der Schlüsselkandidat sowenig Spalten wie möglich haben sollte. Wenn dem nicht so ist, sollte man einen künstlichen Schlüssel verwenden, der diese eindeutig kennzeichnet. Und wenn man über mehrere Tabellen Joint ist es auch für die Performance besser den Index klein zu halten, also ein Integer. (sh. auch advanced SQL)

Thx für Euere Mitarbeit


Was auch sehr empfehlenswert ist:
advanced SQL Studienausgabe - Daniel Warner
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück