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