mysql primary key

[Muggi]

kamm mir jemand in einfachem deutsch erklären, was ein Primary Key ausmacht? Wofür brauch man ihn? Warum ist er wichtig?
Ich möchte jetzt aber keine Links zu google oder mysql.com sondern eine einfache erklärung für snooobs

[King^Lully]

kamm mir jemand in einfachem deutsch erklären, was ein Primary Key ausmacht? Wofür brauch man ihn? Warum ist er wichtig?
Ich möchte jetzt aber keine Links zu google oder mysql.com sondern eine einfache erklärung für snooobs

Wenn Du keinen PK hast und es gibt mehrere Datensätze gleichen Inhalts kannst Du diese nicht aueinanderhalten. Ein PK hat immer einen eindeutigen Wert. Ohne diese Eindeutigkeit hast Du keine konsistente Datenhaltung, d.h. PKs sind essentiell.

[_roro]

kamm mir jemand in einfachem deutsch erklären, was ein Primary Key ausmacht? Wofür brauch man ihn? Warum ist er wichtig?
Ich möchte jetzt aber keine Links zu google oder mysql.com sondern eine einfache erklärung für snooobs

Wenn Du keinen PK hast und es gibt mehrere Datensätze gleichen Inhalts kannst Du diese nicht aueinanderhalten. Ein PK hat immer einen eindeutigen Wert. Ohne diese Eindeutigkeit hast Du keine konsistente Datenhaltung, d.h. PKs sind essentiell.

Kleine Ergänzung: Je nach RDMS ist der PrimaryKey auch ein Index, was beispielsweise dazu führt, dass Abfragen über Diesen die möglichen Datensätze sehr viel schneller aus einer Tabelle rausfischen, als es ohne Index der Fall wäre (WHERE Klausel).

roro

[hans]

Kleine Ergänzung: Je nach RDMS ist der PrimaryKey auch ein Index, was beispielsweise dazu führt, dass Abfragen über Diesen die möglichen Datensätze sehr viel schneller aus einer Tabelle rausfischen, als es ohne Index der Fall wäre (WHERE Klausel).

Hallo,
wieso geht das schneller, wenn ich weiß wie der Key lautet brauche ich doch nicht suchen.
Ich benutze ihn so, suche nach z.B. einen Namen, merke mir den Key und kann später wieder durch den Key zu diesem Satz zurückkehren.
Ich sehe es mehr als Ersatz für eine Datensatznummer die in anderen Datenbanken sowieso schon da ist.
Redundante Daten kann ich weiterhin reinschreiben, nur der Key ist dann unterschiedlich.
Oder irre ich hier.
Gruß Hans

[King^Lully]

Kleine Ergänzung: Je nach RDMS ist der PrimaryKey auch ein Index, was beispielsweise dazu führt, dass Abfragen über Diesen die möglichen Datensätze sehr viel schneller aus einer Tabelle rausfischen, als es ohne Index der Fall wäre (WHERE Klausel).

wieso geht das schneller, wenn ich weiß wie der Key lautet brauche ich doch nicht suchen.

"WHERE (Datentabelle_Index = 15687)" findet den Datensatz dank binärem Suchen deutlich schneller als die Alternative, die darin bestehen würde ohne Index einen "Lauf" auf die Tabelle (a.k.a. table scan) zu machen.

Ich benutze ihn so, suche nach z.B. einen Namen, merke mir den Key und kann später wieder durch den Key zu diesem Satz zurückkehren.

Für die Namenssuche sind normalerweise zusätzliche Indizes anzulegen. Der PK sollte keine weitere Bedeutung haben.

Ich sehe es mehr als Ersatz für eine Datensatznummer die in anderen Datenbanken sowieso schon da ist.
Redundante Daten kann ich weiterhin reinschreiben, nur der Key ist dann unterschiedlich.
Oder irre ich hier.

Die "Datensatznummer, die sowieso da ist", kriegst Du nicht zu packen, wenn Du bspw. zwei Datensätze mit gleichem Inhalt in allen Datenfeldern hast.

[Muggi]

Also ich habe folgende Tabelle:

sender, datum, empfaenger

sender und empfaenger sollen beide gleichzeitig nicht mehr als einmal vorkommen. Hab deshalb

UNIQUE KEY msg (sender, empfaenger)

vergeben damit es nicht zu doppeleinträgen kommt, was auch wie gewünscht funktioniert.
Wie könnte man nun den Primary key einsetzen?
Das Problem ist: Es gibt keine Wert der Einmalig ist. Aber dafür ist die Kombination aus sender-empfaenger einmalig was man ja am UNIQUE KEY erkennen kann.

oder kann man einen Primary Key auch auf "msg" legen? wenn irgendwie möglich möchte ich eine gute performance aus der sache holen.

[Ilja]

yo,

primary keys sind so definiert, dass sie immer zwei eigenschaften (contraints) besitzen müssen. erstens sind sie nicht leer (not null) und sie sind in der entsprechenden tabelle eindeutig (unique). fehlt einer der beiden eigenschaften, dann kann es keine pk sein. unique alleine reicht also nicht aus. soviel zu der definitin eines primary keys.

in der praxis kommt es nun vor, dass eventuell mehrere einzelne spalten, bzw. auch zusammengesetzte spalten diese beiden eigenschaften besitzen. in deinem falle könnte somit sender + empfaenger einen solchen zusammengesetzten pk bilden, wenn du ihnen die oben genannten BEIDEN eigenschaften zuteilst.

zusätzlich kommt noch hinzu, dass es sich in der praxis bewährt hat, keine spalten als pk zu verwenden, die ein attribut (eigenschaft) der jeweiligen tabelle darstellen, sondern künstliche schlüssel zu verwenden, die also nur dazu dienen, jeden datensatz in der tabelle eindeutig zu identifzieren, aber keine weiteren informationen "tragen". der grund dafür liegt darin, dass man den inhalt des pk nicht ändern sollte, sprich der wert bleibt "lebenslang" erhalten. bei sogenannten sprechenden schlüsseln (pk deren wert eine bedeutung hat) besteht immer die gefahr, dass sie sich im laufe des datenbank-lebens doch mal ändert. ein beispiel für einen sprechenden pk wäre zum beispiel das autokennzeichen in einer tabelle auto (internationale autoschilder mal ausgenommen).

so haben wir in unserem derzeitigen projekt in jeder tabelle nur künstliche schlüssel, die aus einzelnen spalten bestehen und deren spaltenname immer mit _pk endet. es ist letzlich eine philosophie und meiner meinung nach auch erfahrungssache, welche spalte man nun zu einem pk macht.

und um endlich auf deine frage zurück zu kommen.

Das Problem ist: Es gibt keine Wert der Einmalig ist. Aber dafür ist die Kombination aus sender-empfaenger einmalig was man ja am UNIQUE KEY erkennen kann.

hier kannst du eine künstliche schlüsselspalte einfügen, die den pk der tabelle darstellt. dann bist du auf jeden fall auf der sicheren seite. es ist aber auch durchaus legitim, die beiden spalten sender und empfanger zusammen als pk zu verwenden, wobei du ihnen dann beide eigenschaften not null und unique zuordnen musst. ich vermute mal, bei den beiden spalten handelt es sich sowieso um fremdschlüsseln zu einer anderen tabelle ?

Ilja

[Muggi]

Danke für die ahsführliche hilfe!

Also zunächstmal folgemdes: Warum sollte ich eine weitere spalte für einen primary key anlegen wenn ich diese nie abfragen würde?
die einzige abfrage die ich mache ist z.b.:

REPLACE INTO messages ('sender', 'empfaenger') VALUES...

Da jeder jedem nur max. eine nachricht schicken soll und bereits vorhandene durch die neue ersetzt werden sollen, muss der datensatz unique sein.

Wenn ich dich also richtig verstehe, sollte ich mal ffolgendes probieren:

UNIQUE INDEX msg (sender, empfaenger)
PRIMARY KEY msg

so habe ich dich zumindestens verstanden!

[Ilja]

yo,

Also zunächstmal folgemdes: Warum sollte ich eine weitere spalte für einen primary key anlegen wenn ich diese nie abfragen würde?

der sinn einen künstlichen schlüssel ist ja, dass er keine informationen trägt, ausser dass er die den datensatz eindeutig identifiert, bzw. die tabellen über FK und PK miteinander verbindet. insofern fragst du ihn schon ab, wenn du einen datensatz bestimmen willst, bzw. wenn du joins bildest. und wenn man den pk und fk noch sinnvolle namen gibst, dann trifft ein pk immer auf einen fk in den abfragen.

speicherplatz ist heute nicht mehr so ein thema wie früher. es ist immer ein abwägen der argumente dafür und dagegen. und es sprechen viele argumte für einen künstlichen schlüssel über nur eine spalte. es ist kein muss, sondern ein rat.

die einzige abfrage die ich mache ist z.b.:
REPLACE INTO messages ('sender', 'empfaenger') VALUES...

die frage ist erst einmal, ob die spalten sender und empfaenger künstliche schlüssel sind oder aber auch andere informationen tragen wie zum beispiel namen. tun sie dass, würde ich davon abraten als schlüssel zu benutzen.

UNIQUE INDEX msg (sender, empfaenger)
PRIMARY KEY msg
so habe ich dich zumindestens verstanden!

richtig, das wäre ein sinnvolle lösung, mit der du auf jeden fall auf der sicheren seite bist.

Ilja