Datenbank Primary Key

[JoltinJoe]

Jo alles klar das hab ich kapiert

Nochmal zu der Frage "Warum lassen sich Daten mit einem PK schneller abrufen?" : Das macht doch nur Sinn wenn in der Abfrage der abzurufende Schlüssel bekannt ist ?

[Hansa]

Zitat von JoltinJoe:

Jo alles klar das hab ich kapiert

Sicher ? Noch ein Beispiel :

Szenario 1 (ohne IDs) : folgende Tables werden für irgendein Programm gebraucht : Artikel, Lager, Statistik, Rechnung. Den 3 letzten müssen dann natürlich Artikel zugeordnet werden. OK, man nimmt die Art.Nr. Da stehen also jetzt in der Lager-,Statistik- und Rechnungstabelle z.B. Datensätze mit artnr = 100. Der User verspürt aber plötzlich Lust, für den entsprechenden Artikel artnr = 1000 zu verwenden. Was ist zu tun ? Die 3 vom Artikel abhängigen Tabellen müssen komplett nach artnr = 100 durchsucht werden und an allen Fundstellen durch artnr = 1000 ersetzt werden. Im Prinzip kann erst wenn alle auf 1000 gesetzt sind der entsprechende Artikel selbst von artnr = 100 auf 1000 geändert werden.

Szenario 2 (mit IDs) : Artikel kriegt zusätzlich eine ID. Und diese wird automatisch per Generator/Trigger hochgezählt. Dann ist sie sofort eindeutig. Auch die drei anderen Tabellen erhalten vorsichtshalber eine ID und auch (und jetzt kommt das Wichtige) eine IDart. Also steht da nicht mehr ein Feld artnr = 100, sondern das Feld IDart = 95 (bspw.). Die 95 stammt von dem Artikel mit Nr. 100, der die ID = 95 hat. Was muss hier jetzt bei Änderung der Art.Nr. von 100 auf 1000 gemacht werden ? Einfach das Feld Art.Nr. von 100 auf 1000 ändern. Das wars. Die 95 bleibt ja, wie sie ist. Für die Rechnung- usw. Tabellen, ist der Artikel dadurch immer noch eindeutig zu lokalisieren. Da braucht überhaupt nichts gemacht zu werden !

Man sieht hier sehr oft weggelassene IDs oder so was wie bereits gesagt : PK für Name und dann noch die Str. mitschleppen usw. Was aber, wenn in einem Haus 2 Meier wohnen ? Ich sage nur : Murphy lässt grüssen. Mal ganz davon abgesehen, dass ein PK aus Name, Strasse, Ort oder womöglich noch mehr viel zu gross wird. ID hätte lediglich 4 Byte.

[JoltinJoe]

Ja, wie schon erwähnt...das hab ich kapiert.

Ich war nur etwas verwirrt weil, anscheinend ein labersack, mal meinte "wenn du kein pk hast, dann wird es Ewigkeiten dauern einen String in deinem Feld zu finden" ...

[mkinzler]

Wenn die Tabelle sehr groß ist, kann es schon dauern, wird dieses Feld dann zufällig zum PK, kann es schon schnneller werden ( wenn nicht auf like gesucht wird). Ich glaube aber er hat PK mit Index verwechselt/gleichgesetzt

[JoltinJoe]

Hm ja möglicherweise. Aber auf einen Primärschlüssel wird doch automatisch ein Index gelegt? Möglicherweise hat er das verwechselt.

[DeddyH]

Jedes PK-Feld wird automatisch indiziert, aber nicht jedes indizierte Feld wird automatisch PK (wie soll das auch funktionieren?).

[JoltinJoe]

Ja, das hat auch keiner behauptet Ich denke ich habe vorerst genug Informationen.. Danke !

bYe

[Stevie]

Zitat von Hansa:

Szenario 1 (ohne IDs) : folgende Tables werden für irgendein Programm gebraucht : Artikel, Lager, Statistik, Rechnung. Den 3 letzten müssen dann natürlich Artikel zugeordnet werden. OK, man nimmt die Art.Nr. Da stehen also jetzt in der Lager-,Statistik- und Rechnungstabelle z.B. Datensätze mit artnr = 100. Der User verspürt aber plötzlich Lust, für den entsprechenden Artikel artnr = 1000 zu verwenden. Was ist zu tun ? Die 3 vom Artikel abhängigen Tabellen müssen komplett nach artnr = 100 durchsucht werden und an allen Fundstellen durch artnr = 1000 ersetzt werden. Im Prinzip kann erst wenn alle auf 1000 gesetzt sind der entsprechende Artikel selbst von artnr = 100 auf 1000 geändert werden.

Dafür gibts aber on update cascade foreign keys. (erwähn ich nur der Vollständigkeit halber, ich find die auch eher sinnlos)
Mich wundert übrigens, dass hier noch nicht das Wort Normalisierung gefallen ist (oder hab ichs überlesen?)

[mkinzler]

Zitat:

Mich wundert übrigens, dass hier noch nicht das Wort Normalisierung gefallen ist (oder hab ichs überlesen?)

So in die Tiefe gehen wollten wird bisher noch nicht