# braucht man einen primary key



## ruhrbengel32 (26. Oktober 2004)

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


----------



## KristophS (26. Oktober 2004)

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.


----------



## ManicMarble (27. Oktober 2004)

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


----------



## mschuetzda (27. Oktober 2004)

... und es hat den Vorteil, dass man die eigentlich eindeutigen "primary key Kandidaten" ohne Folgeprobleme updaten bzw. ändern/korrigieren kann,.


----------



## Radhad (28. Oktober 2004)

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.


----------



## mschuetzda (28. Oktober 2004)

ja aber,  nicht Normalform hat manchmal theopraktische Vorteile.


----------



## ManicMarble (28. Oktober 2004)

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.



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


----------



## Geshrec22 (30. Oktober 2004)

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...


----------



## ManicMarble (30. Oktober 2004)

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"  .


----------



## Geshrec22 (30. Oktober 2004)

mhja... hast auch wieder recht 
 ich hab den fall auch gerade ^^
 vonwegen pfriemeln....

 Übrigens danke nochmal für deine Hilfe in dem anderen Thread....


----------

