braucht man einen primary key

R

ruhrbengel32

Grünschnabel
Hallo Leute.

Ich habe in mysql eine datenbank mit folgender tabelle:

create table art_order (
orderid int not null references kd_order(orderid),
artid int not null references artikel(artikelnr),
menge int(3)) type=innodb;

Zuvor hatte ich noch

primary key(orderid, artikelid)

gesetzt , danach hatte ich einen fehler beim einfügen der daten, was ja auch logisch ist, denn wenn ein kunde zweimal dasselbe teil kauft hätte ich nun zwei gleiche einträger in der tabelle und das wäre ja bei einem vorhandenen primary key falsch, oder
 
Ja. ein Primary Key muss 'unique' sein, also einzigartig.
Primary Keys sind nicht unb. noetig, sind aber nicht schlecht.
Fuer mehr einfach mal die DOKU deiner Datenbank lesen.
 
Ein Grundsatz, der eigentlich nie schaden kann:
Absolut jede Tabelle kriegt als erstes Feld ein unsigned-int[11]-auto_increment-Feld. Das wird der Primary Key.
Ich mache das bei allen meinen Projekten so, es hat sich noch nie als unnötig rausgestellt und schon oft geholfen. Man hat immer eine eindeutige Datensatz-ID, allein das ist schon fast ein Muss. Man kann problemlos mit LAST_INSERT_ID() arbeiten - großer Vorteil. Man kann immer 100%ig sicher bestimmen, welcher Datensatz ge-updated werden soll (UPDATE ... WHERE id = '123').

Martin
 
... und es hat den Vorteil, dass man die eigentlich eindeutigen "primary key Kandidaten" ohne Folgeprobleme updaten bzw. ändern/korrigieren kann,.
 
Hat nur einen Nachteil, wenn die Tabelle selbst aus einem Mehrteiligen Primary Key besteht, wo die ID eigentlich unnötig ist... Also laut Normalform würde ich nicht immer eine ID einführen.
 
Radhad hat gesagt.:
Hat nur einen Nachteil, wenn die Tabelle selbst aus einem Mehrteiligen Primary Key besteht, wo die ID eigentlich unnötig ist... Also laut Normalform würde ich nicht immer eine ID einführen.
Zum Vergrößern anklicken....

Normalisierung hin oder her - für mich zählt der praktische Nutzen. Und eine ID-Spalte mag ja manchmal tatsächlich überflüssig sein, wirklich schaden tut sie eigentlich nie.

Natürlich gibt es (oft) Fälle, wo andere Schlüssel gebraucht werden, die sind auch oft kombiniert und/oder UNIQUE. Aber PRIMARY ist bei mir einfach immer die ID.
Selbst reine n:m-Beziehungs-Tabellen haben bei mir mindestens 3 Spalten: neben den Verknüpfungs-Spalten (bspw. x_id und y_id) die von mir aus auch indiziert sind gibts eben noch die Primary-Key-auto_increment-Spalte id, die den Verknüpfungs-Tabellen-Datensatz eindeutig identifiziert. Ja, das ist manchmal nicht nötig - oft stellt's sich aber später als hilfreich heraus.

Martin
 
Hmmm ich war bisher eigentlich auch immer der Meinung das ein dritter Column bei n:m Sachen sinnlos ist... Kannst du mal genauer spezifizieren wobei die dritte Spalte hilfreich sein könnte? Würde mich interessieren...
 
Ok, ich ändere die Wortwahl:
Es ist OFT nicht nötig - MANCHMAL stellt's sich aber später als hilfreich heraus.

Hilfreich ist's zum Beispiel, wenn man per PHP eine HTML-Dropdown-Liste füllt (<select>). Man kann dann bei den <option>s einfach die ID der Beziehungs-Tabelle als value hernehmen. Gäb's die nicht, dann müsste man als eindeutige DS-Identifikation eine Kombination aus x_id und y_id mit einem Trennzeichen dazwischen basteln und das dann wieder auseinanderpfriemeln, um den vom Anwender ausgewählten Beziehungs-Datensatz exakt zu bestimmen. Klar, das geht auch, ist aber umständlich. Ich schrieb ja auch "hilfreich" und nicht "notwendig" ;) .
 
mhja... hast auch wieder recht
ich hab den fall auch gerade ^^
vonwegen pfriemeln....

Übrigens danke nochmal für deine Hilfe in dem anderen Thread....
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück