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