PrimaryKeys - welchen nehme ich?

[Eddie]

Hallo allerseits,

ich habe in einer Tabelle ein Attribut "URL" (varchar(255)), das bereits minimal identifizierend ist. Spricht irgendwas dagegen, das dann auch als Primary Key einzusetzen? Oder sollte ich besser einen extra Schluessel einfuehren?

Danke für eure Hilfe,
Eddie

[Rouven]

Hallo,

das ist eine Prinzipienfrage. Prinzipiell kann man einen eindeutigen Wert natürlich als Schlüssel verwenden, man sollte sich allerdings der Konsequenzen bewusst sein. Wenn das zugrunde liegende Datenmodell wächst, dann werden früher oder später Beziehungen zu dieser Tabelle entstehen. Wenn du nicht mit einem künstlichen Schlüssel arbeitest, musst du die URL in den anderen Tabellen als Fremdschlüssel verwenden. Das ist speichertechnisch evtl. nicht sehr effizient.
Was in aller Regel schwerer wiegt ist die Frage "was passiert wenn sich eine URL ändert?" Im Normalfall (künstlicher Schlüssel), na ja Gott, da passt man halt die URL an, alle Schlüssel sind gewahrt. Wählst du allerdings einen sprechenden Schlüssel, dann zieht diese Änderung einen riesigen Rattenschwanz nach sich, weil du plötzlich überall die Fremdschlüssel anpassen muss. Das ist eine Situation, die man eigentlich gerne vermeiden möchte.

MfG
Rouven

[Sven Rautenberg]

Moin!

ich habe in einer Tabelle ein Attribut "URL" (varchar(255)), das bereits minimal identifizierend ist. Spricht irgendwas dagegen, das dann auch als Primary Key einzusetzen? Oder sollte ich besser einen extra Schluessel einfuehren?

Ein Schlüssel des Typs varchar(255) benötigt schlimmstenfalls 255 Byte je Dateneintrag - auch bei Referenzierungen in anderen Tabellen.

Ein Schlüssel vom Typ BIGINT benötigt 8 Byte (kleinere Int-Typen entsprechend weniger). Eine URL hingegen benötigt ja schon mindestens 3 Zeichen für "://", dann noch 3 bis 4 Zeichen für das Protokoll (ftp, http,...), und die Domain besteht auch mindestens aus 4 Zeichen (Länderdomain plus kürzestmögliche SecondLevelDomain = x.yz). In der Summe also 10 Bytes für eine extrem unwahrscheinliche URL.

Natürlich muß die URL so oder so gespeichert werden, egal ob sie nun Primary Key ist, oder nicht. Aber der Sinn eines Primärschlüssels ist ja gerade, ihn als Fremdschlüssel in anderen Tabellen zu verwenden - und genau da wirds dann verschwenderisch beim Speicherplatz.

Die URL grundsätzlich als UNIQUE-Index zu definieren ist davon unabhängig - dient aber in erster Linie dazu, dass die Datenbank Duplikate verhindert. Aber gerade sowas ist bei URLs problematisch, denn zwei unterschiedliche URLs können dennoch die gleiche Ressource bezeichnen - sei es durch Redirect, serverinterne Duplizierung oder unterschiedliche Codierung der URL. Umgekehrt kann unter einer einzigen URL durchaus unterschiedlicher Content erreichbar sein (Content Negotiation mit unterschiedlichen Sprachen oder Kompression).

Eine URL ist daher bei genauer Betrachtung gar nicht so einzigartig, wie man es vielleicht gerne hätte. Und damit potentiell ungeeignet als Key in der Datenbank.

- Sven Rautenberg

[Frank (no reg)]

Salut,

d'accord zum grössten Teil.

Es hängt auch teilweise vom verwendeten DBMS ab, wie es mit mit Primary
Keys umgeht. Und es muss nicht immer der PK einer Tabelle sein, der
für Foreign Key Beziehungen verwendet werden kann. Evt. kann man auch
Unique Keys verwenden. Und imho liegt der hauptsächliche Sinn des PK
darin, den Datensatz in einer Tabelle physikalisch eindeutig zu identi-
fizieren. U.U. entscheidet der PK dann auch über die physikalische
Reihenfolge der Datensätze.

In dem Fall sollte man folgende Best Practices zum PK befolgen:

• so klein wie möglich, so gross wie nötig
• eindeutig und statisch (unveränderlich)
• sequentiell fortlaufend

Grüsse und einen hübsch heissen Arbeitstag :)
Frank

[Ilja]

yo,

Und imho liegt der hauptsächliche Sinn des PK
darin, den Datensatz in einer Tabelle physikalisch eindeutig zu identi-
fizieren.

ich würde da eher logisch zu sagen. zum beispiel wäre bei oracle nicht der pk, sondern die rowid für die physikalische speicherung zuständig.

U.U. entscheidet der PK dann auch über die physikalische
Reihenfolge der Datensätze.

wäre mir neu, bzw, was genau meinst du damit ?

• sequentiell fortlaufend

nicht wirklich, es werden zwar gerne autoincrement werte genommen, weil das wohl der einfachste weg ist, um den kind einen eindeutigen namen zu geben. aber bei tabellen handelt es sich sowieso um eine unsortierte menge, insofern spielt es auch keine rolle, wenn sie nicht sequentiell fortlaufend sind.

Ilja

[Frank (no reg)]

Hi,

deswegen schrieb ich als 2. Satz, es hängt vom verwendeten Datenbank-
system ab. Dafür hast du ja auch das Beispiel mit der rowid von Oracle
gebracht. :)

sondern die rowid für die physikalische speicherung zuständig
tabellen handelt es sich sowieso um eine unsortierte menge

Widersprichst du dir da nicht etwas selbst? Wenn die physikalische
Speicherung sich durch die rowid ausdrückt und diese durch einen
Algorithmus bestimmbar ist, dann ist die rowid ordbar und somit die
ganze Tabelle keine unsortierte Menge mehr. Und auch sonst, wenn
die Menge unsortiert ist, wie willst du gewährleisten, dass zum
deinem Schlüssel X die richtigen Werte gelesen werden, irgendwo
muss dann eine Verbindung zur physikalischen Speichermenge bestehen....

Im Falle von MS SQL Server existieren die Clustered und Nonclustered
Keys. Der (es ist nur einer möglich) Clustered Key einer Tabelle
bestimmt die physikalische Reihenfolge der Daten in der Tabelle. Man
kann zwar auch reine Heaptabellen ohne Ordnung anlegen (-> unsortierte
Menge) aber im Normalfall sind Tabellen in MS SQL über ihren Clustered
Key geordnet. Und da für den Clustered Key fast identische Anforderungen
(aus logischer Sicht) gelten wie für einen Primary Key wird beides
meist zusammen als PRIMARY KEY CLUSTERED.

Der Sinn von dann sequentiell fortlaufenden Werten für den Key
besteht darin, dass die neue Daten immer am Ende der Datenmenge
angehängt werden und keine Splits innerhalb der Datenmenge
durchgeführt werden müssen, was unweigerlich zur Fragmentierung
führt. Insofern ist die vielverfolgte Ideologie von .Net Entwicklern,
eine Guid zum PK zu machen, kontraförderlich mit steigender Daten-
menge. (Die Gründe kannst du dir denken).

Aber, eben, wie ich sagte, es ist abhängig vom DBMS, wie es seine
Speicherallokation für Daten vornimmt. Und schaden tut ein
sequentiell fortlaufender key sicher nicht, und bequem zu
produzieren ist er auch :)

Als denn, Frank

[wahsaga]

hi,

Und schaden tut ein sequentiell fortlaufender key sicher nicht, und bequem zu produzieren ist er auch :)

Aber nicht so bequem beizubehalten, wenn Datensätze gelöscht werden.

gruß,
wahsaga

[Frank (no reg)]

Hallo,

Aber nicht so bequem beizubehalten, wenn Datensätze gelöscht

werden.

Könntest du dich bitte etwas näher erklären? Was willst du
beibehalten und warum? Zielst du auf das Wiederauffüllen von
Lücken, die durch Löschen entstanden sind? Das macht keinen Sinn.

Ciao, Frank

[wahsaga]

hi,

Zielst du auf das Wiederauffüllen von
Lücken, die durch Löschen entstanden sind? Das macht keinen Sinn.

Eben.

gruß,
wahsaga

[Frank (no reg)]

Hab ich ursprünglich behauptet, dass es mir darum gänge?

FF

[Eddie]

Hallo Frank,

Aber nicht so bequem beizubehalten, wenn Datensätze gelöscht
werden.

[...] Zielst du auf das Wiederauffüllen von
Lücken, die durch Löschen entstanden sind? Das macht keinen Sinn.

Warum macht das keinen Sinn? Wenn ich einen begrenzten Wertebereich fuer meinen Primary Key habe (bspw. int), dann komme ich doch automatisch irgendwann ans Ende - auch wenn meine DB dann nur einen einzigen Eintrag hat. Oder?

Und falls ich das nicht vollkommen falsch sehe: wie bekomme ich die Luecken dann gestopft? Macht das mein DBMS automatisch, oder bin ich mit autoincrement dann tatsaechlich am Ende?

Eddie

[Frank (no reg)]

Hallo,

int32 = int hat einen hat einen Wertebereich von ca. 2 Millarden wenn
man nur die positiven Werte nimmt aber ein Vorzeichen per Definition
ermöglicht.

Wann wirst du die Grenze voraussichtlich erreichzen? Zur not gibt es
noch int64 = long .. verbraucht nur 4 byte mehr als ein int32 und
kann dafür 9.223.372.036.854.775.807 positive Werte annehmen. Und
dann gibt es auch noch int128 ... :)

Warum es u.a. keinen Sinn macht:

• weil der Aufwand, die Lücken zu finden ungerechtfertigt hoch wäre (extra queries)
• weil es kein technisch rechtfertigendes Argument gibt, es zu tun

... mehr fällt mir ad-hoc dazu grad nicht ein ... biernot :)
Aber das Archiv dieses tollen Forums kann dir sicher noch weitere
Argumente liefern.

Ein PK ist ein rein technisches Feature von DBMS um für sich Datensätze
eindeutig zu identifizieren. Es sollte nie für Geschäftszwecke verwendet,
also einen Sinn jenseits der technischen Bedüütig haben. Eben aus o.g.
Gründen, dass das Auffüllen von Lücken unnötiger Aufwand ist.

So long,
Frank

[wahsaga]

hi,

[...] Zielst du auf das Wiederauffüllen von
Lücken, die durch Löschen entstanden sind? Das macht keinen Sinn.

Warum macht das keinen Sinn? Wenn ich einen begrenzten Wertebereich fuer meinen Primary Key habe (bspw. int), dann komme ich doch automatisch irgendwann ans Ende - auch wenn meine DB dann nur einen einzigen Eintrag hat. Oder?

Dann sorgst du halt rechtzeitig dafür, dass dein Wertebereich nicht so schnell erschöpft ist.

Und falls ich das nicht vollkommen falsch sehe: wie bekomme ich die Luecken dann gestopft? Macht das mein DBMS automatisch, oder bin ich mit autoincrement dann tatsaechlich am Ende?

Du willst sie nicht stopfen, weil das absolut überflüssig ist, und dich schlimmstenfalls zu Dateninkonsistenzen führt. (Denke nur an einen gelöschten Datensatz mit der ID XY, zu dem in einer anderen Tabelle vielleicht noch eine Referenz besteht, weil das Löschen in dieser Fehlschlug oder vergessen wurde. Jetzt legst du einen neuen Datensatz mit der ID XY an - und plötzlich verweist aus der anderen Tabelle ein Datensatz auf diesen, obwohl er absolut nichts mit ihm zu tun hat. Kann doch nicht gewollt sein.)

gruß,
wahsaga

[Ilja]

yo,

deswegen schrieb ich als 2. Satz, es hängt vom verwendeten Datenbank-
system ab. Dafür hast du ja auch das Beispiel mit der rowid von Oracle
gebracht. :)

das hat mit orakel nichts zu tun, sondern kein dbms hat als pk einen bezug zu der physikalischen speicherung. wie sollte das im falle eines autoincrement wertes auch aussehen ? ich habe dann zum beispiel den wert 1373 für einen datensatz, der damit eindeutig in der tabelle idientiziert wird. und wie drückt sich mit dieser zahl der physikalische speicherort aus ? ich kann daran nicht physikalische, sondern nur logisches erkennen.

Widersprichst du dir da nicht etwas selbst? Wenn die physikalische
Speicherung sich durch die rowid ausdrückt und diese durch einen
Algorithmus bestimmbar ist, dann ist die rowid ordbar und somit die
ganze Tabelle keine unsortierte Menge mehr.

wie kommst du den darauf, was hat das eine mit dem anderen zu tun ? wenn ich einen plan habe, wo ich einen apfel und eine birne bei mir in der küche finden kann, da ist doch damit noch nicht gesagt, in welcher reihenfolge ich das obst essen werde.

Und auch sonst, wenn
die Menge unsortiert ist, wie willst du gewährleisten, dass zum
deinem Schlüssel X die richtigen Werte gelesen werden, irgendwo
muss dann eine Verbindung zur physikalischen Speichermenge bestehen....

relationale dbms bestehen auf der grundlage der mengenlehre. insofern sind alle tabellen per definition unsortiert. wie sollte es auch anders sei, die sortierreihenfolge kann sich ja je nach abfrage ändern. ich kann doch nicht für jede mögliche art der sortierung die daten abspeichern, nur damit sie hintereinander stehen.

Der Sinn von dann sequentiell fortlaufenden Werten für den Key
besteht darin, dass die neue Daten immer am Ende der Datenmenge
angehängt werden und keine Splits innerhalb der Datenmenge
durchgeführt werden müssen, was unweigerlich zur Fragmentierung
führt.

diese aussage kann ich für dbms nicht bestätigen. woher beziehst du diese information. wie gesagt, bei abfragen ist es doch in aller regel schnuppe, in welcher reifenfolge die pk nun gewählt werden, sondern nur, das er eindeutig ist und nicht NULL. autoincrement-werte sind doch nur deswegen so sinnvoll, weil es so schön einfach ist, den datensätzen einen eindeutigen namen zu geben. es könnte aber durchaus auch ganz "ungeordnet" passieren und das dbms hätte  damit keine probleme.

Aber, eben, wie ich sagte, es ist abhängig vom DBMS, wie es seine
Speicherallokation für Daten vornimmt. Und schaden tut ein
sequentiell fortlaufender key sicher nicht, und bequem zu
produzieren ist er auch :)

wie genau nun ein dbms seine daten physikalisch speichert, dass ist sicherlich individuell. aber es hängt mit sicherheit nicht von dem -> inhalt <- des pk ab. und nur dann würde es einen physikalischen bezug geben können.

Ilja

[Frank (no reg)]

kurze Gegenfrage:

Wenn du Birnen in deiner Küche suchst, fängst du dann zwischen den
Äpfeln an zu suchen?

Ciao, Frank

[wahsaga]

hi,

Wenn du Birnen in deiner Küche suchst, fängst du dann zwischen den
Äpfeln an zu suchen?

Dafür hast du ja ein DBMS - dass du gar nicht zwischen irgendwas suchen musst. Sondern einfach sagst, gib mir alle Birnen, und gut is'.

gruß,
wahsaga

[Frank (no reg)]

Ja, toll ... klasse Antwort, und stell dir vor, du bist jetzt das DBMS. Mit welchen Hilfsmitteln gehst du als DBMS auf die Suche nach den Datensätzen?

• Für jedes gefundene, annähernd runde Objekt tue
    - kosten
      - wenn schmeckt wie Birne = richtiges Objekt
      - wenn nicht, weiter
    .. nächstes Objekt

oder

• Birnen liegen frühestens in Stiege 2, also brauch ich in Stiege 1 gar nicht suchen, spart Zeit und ich muss keine Pferdeäpfel kosten ;)

...

Das (welche Anstrengung das DBMS zur Lokalisierung von Datensätzen unternehmen muss) ist genau der Kernpunkt der Diskussion, an dem du leider vorbeigeschrammt bist.

Adios, so long
Frank

[wahsaga]

hi,

Ja, toll ... klasse Antwort, und stell dir vor, du bist jetzt das DBMS. Mit welchen Hilfsmitteln gehst du als DBMS auf die Suche nach den Datensätzen?

• Für jedes gefundene, annähernd runde Objekt tue
    - kosten
      - wenn schmeckt wie Birne = richtiges Objekt
      - wenn nicht, weiter
    .. nächstes Objekt

Wenn ich dummerweise keinen geeigneten Index hätte, müsste ich das wohl tun, ja.

oder

• Birnen liegen frühestens in Stiege 2, also brauch ich in Stiege 1 gar nicht suchen, spart Zeit und ich muss keine Pferdeäpfel kosten ;)

...

Ja, ein (binärer) Suchbaum würde mir hierbei sicherlich schon ein wenig weiterhelfen.

Aber der wird dann sicherlich auf der Spalte "Obstart" liegen - und nicht auf dem PK, der - wenn ich dich mit deiner Argumentation für einen "fortlaufenden" PK richtig verstanden habe - wohl als sowas wie das "Einlieferungsdatum" verstanden werden könnte.

Nein, mich interessiert beim Suchen kein Bisschen, ob eine Birne als erstes Stück Obst, als 711tes oder als 3782tes eingeliefert wurde.
Was mich interessiert ist, dass sie alle in der Kiste mit der Aufschrift "Birnen" liegen. Das ist aber der Index auf der Obstart, und hat mit dem PK absolut nichts zu tun.

Das (welche Anstrengung das DBMS zur Lokalisierung von Datensätzen unternehmen muss) ist genau der Kernpunkt der Diskussion, an dem du leider vorbeigeschrammt bist.

Irgendwie habe ich das gefühl, dass du diesbezüglich noch ein wenig weiter vom Weg abgekommen bist als ich.

gruß,
wahsaga

[Frank (no reg)]

Ja, irgendwie reden wir etwas aneinander vorbei ... ich hab mich dummer-
weise weiter auf die Obst- und Gemüsediskussion eingelassen. (Die ging
in eine andere Richtung)

Vielleicht desterwegen einfach nochmal Klartext (zmd. ein Versuch):

Unter der Voraussetzung, dass ein DBMS nicht nur Heaptabellen hat, sondern
Tabellen, deren Inhalte sortiert (PK, da sind wir uns doch einig, dass
ein PK eine Sortierung hat) sind, ist es physikalisch für das DBMS von
Vorteil, wenn neue Daten(sätze) sequentiell am Ende (der Blöcke, Seiten,
Nodes) angefügt werden, da damit eine implizite Neuorganisation der
Sortierung (Splits) und Verschiebung von Daten unterbunden wird. Es
führt zu einer kompakteren, weniger fragmentierten physikalischen
Speicherung der eigentlichen Daten so dass weniger Lese/Schreib-Sprünge
zwischen den physikalischen Einheiten notwendig sind, was bei grossen
Datenmengen zu höherer Transaktionsverarbeitung führt.

Das mag bei verschiedenen DBMS mehr oder weniger deutlich oder
beeinflussend implementiert sein.

Bei MS SQL und allem darauf basierenden ist es eine Best Practice,
das physikalische Modell so zu implementieren.

Vielleich hätte ich das "MS SQL" heute früh um Sieben mit hinzufügen
sollen, um missverständnisse zu vermeiden, aber dafür war ich noch
nicht ausgeschlafen genug. Mir geht es auch nicht darum, zu sagen,
dass es jetzt mit MS SQL ultratoll gelöst ist, definitiv nicht,
sondern nur darum, dass es gewisse Prinzipien gibt, an die man sich
als Entwickler halten sollte, wenn man mit RDBMS'sen arbeitet.

Als denn,
Frank

[wahsaga]

hi,

Unter der Voraussetzung, dass ein DBMS nicht nur Heaptabellen hat, sondern Tabellen, deren Inhalte sortiert (PK, da sind wir uns doch einig, dass ein PK eine Sortierung hat) sind,

Nein, da sind wir uns nicht einig.

ist es physikalisch für das DBMS von
Vorteil, wenn neue Daten(sätze) sequentiell am Ende (der Blöcke, Seiten,
Nodes) angefügt werden, da damit eine implizite Neuorganisation der
Sortierung (Splits) und Verschiebung von Daten unterbunden wird. Es
führt zu einer kompakteren, weniger fragmentierten physikalischen
Speicherung der eigentlichen Daten so dass weniger Lese/Schreib-Sprünge
zwischen den physikalischen Einheiten notwendig sind, was bei grossen
Datenmengen zu höherer Transaktionsverarbeitung führt.

Das mag ja sein - aber was hat der PK damit zu tun?

Das mag bei verschiedenen DBMS mehr oder weniger deutlich oder
beeinflussend implementiert sein.

Ode rauch gar nicht?

Bei MS SQL und allem darauf basierenden ist es eine Best Practice,
das physikalische Modell so zu implementieren.

Vielleich hätte ich das "MS SQL" heute früh um Sieben mit hinzufügen

Wenn du mit der internen Arbeitsweise des DBMS MS SQL so vertraut bist, nehme ich das mal als Tatsache hin.
Aber daraus auf das Verhalten anderer DBMS zu schließen, würde ich nicht wagen.

gruß,
wahsaga

[Ilja]

yo,

Wenn du Birnen in deiner Küche suchst, fängst du dann zwischen den
Äpfeln an zu suchen?

wie wahsaga schon sagte, bin ich gar nicht dafür verantworlich, wo die birnen und die äpfel nun sind. genau diese eigenschaft ist es, die datenbanken so universell macht.

aber um von dem beispiel mit dem obst ein wenig wegzukommen und wieder hin zu dem pk. dein argument ist es ja, die datensätze mit "ähnlichen" bzw. forlaufenden inhalten zusammen zu halten, um abfragen letztlich effizienter zu machen. dies ist aber ein trugschluss. die aufgabe eines pk ist einzig und allein, den datensatz eindeutig zu identifizieren und nichts weiter.

die eigenschaft, dass es sich bei dem einen pk eventuell um den nachfolger handelt (zum beispiel datensatz 14 und 15), hat überhaupt keine aussage darüber, ob diese beiden datensätze auch nun öfter zusammen abgerufen werden. ganz im gegenteil sind es allen anderen spalten aber nicht der pk. so könnte ich mir vorstellen, orte mit gleichen inhalt zusammen zuhalten oder datensätze, die über ein fremdschlüssel miteinander verbunden sind. dort ist die wahrscheinlichkeit wesentlich höher, dass ich sie zusammen abrufe. aber genau solche eine aussage kann ich über den pk nicht machen.

Ilja

[Frank (no reg)]

Hallo nochmal,

auf die Effizienz bei Abfragen, dass 15 nach 14 kommt wollte ich gar
hinaus, sondern auf der anderen Seite, wenn es darum geht, Daten zu
schreiben. Also nix mit "öfter gemeinsam abgerufen werden".

bin ich gar nicht dafür verantworlich, wo die birnen und die äpfel nun sind.

d'accord, hab ich auch nie behauptet. Das DBMS trägt die Verantwortung
dafür, einen beliebigen Datensatz X anhand deiner Kriterien zu finden
und dies zudem noch in einer entsprechend kurzen Zeit. Dazu kann es
die ganze Tabelle von vorn (einen Anfang muss die Tabelle ja haben)
bis hinten (ein Ende auch) one by one durchsuchen, bis es einen oder
entsprechend viele gefunden hat, die deinem Kriterium entsprechen.

Und damit dies schneller vonstatten geht, benutzt man Indizes, denn
diese, da wirst du mir sicher nicht widersprechen wollen, sind sortiert.
Was ist denn genau der Primary Key einer Tabelle? Basiert er nicht auf
einem Index? Und welche Daten beinhaltet er? Und warum?
... damit das DBMS weiss, an welcher Stelle es mehr oder weniger Sinn
macht im Datenbrei von Bytes zu lesen.

Was passiert, wenn es keinen einzigen Index oder Primary Key auf einer
Tabelle gibt? Ein Full Table Scan, das hatten wir ja grad schon

Keine Ahnung, wie MySQL seine Datensätze physikalisch ausfindig macht,
jedoch wird es wohl nicht viel anders funktionieren.
Bei Oracle ist lt. deiner Aussage die RowId für die physikalische
Speicherung verantwortlich, wie funktioniert diese RowId?
Zufallswerte?

Stell dir einfach vor eine Tabelle mit einem alphanumerischen PK: A-Z0-9
Key     | Payload
-----------------------------------------------
Alf     | Hello World !
Frei    | Hello Ilja !
Kohl    | Hello wahsaga !
Zauber  | Hello SelfHtml !
im Datenbrei sieht das dann so aus (Beispiel)

Alf|Hello World !||Frei|Hello Ilja !||Kohl|Hello wahsaga !||Zauber|Hello SelfHtml !EOF

Jetzt kommt ein weiterer Datensatz hinzu,

Key     | Payload
-----------------------------------------------
Muster  | Hello Cheatah !

Wo wird dieser im Datenbrei dann hingeschrieben?

[ ] Ans Ende     (wäre vernünftig und nicht unlogisch)
[ ] Zwischen "Kohl" und "Zauber"  (wäre das unlogisch?)

Wo wird der Schlüssel-Wert des PK hingeschrieben?
[ ] Ans Ende     (warum?)
[ ] Zwischen "Kohl" und "Zauber"  (warum?)

Was passiert im jeweils 2. Fall? Alles nach "Muster" kommt muss um
die Datenmenge des neuen Eintrages (Tabelle oder Index Node)
verschoben werden. In sofern wäre es günstig, wenn das nur beim Index
bzw. dem PK notwendig wäre, weil weniger Daten, oder?

Am Beispiel MS SQL kann ich dem Primary Key sagen, dass er für die
Ordnung der Daten in den Blöcken und Seiten verantwortlich ist.
Ein numerischer PK mit aufsteigender Sortierordnung würde also
Datensätze, die einen niedrigen Schlüsselwert haben, am Anfang
speichern... usw. Lass ich den PK weg habe ich, wie du das so schön
behauptest, eine wirklich unsortierte Menge. Ansonsten eine sortierte.

Ein streng fortlaufender Schlüsselwert ist sofern generell besser,
da er mindestens an einer Stelle das wiederholte unnötige Verschieben
von Daten unterdrücken kann, da neue Daten generell nur am Ende
angefügt werden. Weniger Fragmentierung, weniger Leseaufwand usw.
Alles was ich mitteilen wollte.

Aber kläre doch mal bitte über Oracles RowID auf, oder wie es sich
bei MySQL verhält, das wäre sicher informativ für das Publikum.

Ich hoffe, das ist jetzt angekommen.
Cheers,
Frank

[Ilja]

yo,

grundsätzlich bleibe ich dabei, das der inhalt des pk keinen bezug auf die physikalische reihenfolge der speicherung hat.

allerdings habe ich ein wenig in einem mssql buch geschnuppert und festgestellt, dass mssql nicht nur einen index für einen pk anlegt, was einen zeiger auf den eigentlich datensatz beinhalten würde, welche wiederum unsortiert abgespeichert würden, sondern einen sogenannten gruppierten index, den du auch bei deinem letzten post angesprochen hast. insofern liegt mit einem pk auch automatisch eine sortierte tabelle unter mssql vor. aber dies ist nicht die regel und kann man somit auch nicht auf den pk verallgemeinern. hier geht mssql offensichtlich einen eigenen weg.

Bei Oracle ist lt. deiner Aussage die RowId für die physikalische
Speicherung verantwortlich, wie funktioniert diese RowId?
Zufallswerte?

eher umgekehrt, die rowid bestimmt nicht, wo etwas gespeichert wird, sondern beinhaltet vielmehr, wo der datensatz gespeichert wurde.

Ilja

[Eddie]

Danke euch beiden, hat mir sehr geholfen! Warum ich selbst nicht soweit gedacht habe (was den Speicherplatz und die Persistenz angeht), weiss ich jetzt auch nicht... Naja, 's ist ja schon spaet... :-)

Eddie