nicht angemeldet
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