da wir gerade in den Alaska-News etwas abschweifen, mache ich hier mal ein Thema auf und hoffe, dass wir die entsprechenden Fragen hierüber leiten können.
Vor gut 30 Jahren stellte die IBM in Bezug auf ihre DB/2 Datenbank auf dem System /38 fest (sinngemäss, ich habe die Handbücher nicht mehr):
Gerade bei grossen Datenmengen kann ein Index die Verarbeitung deutlich verlangsamen, weil der Index (bei der DB/2 war es ein B-Tree, wenn ich mich recht erinnere) angepasst werden musste. Im schlimmsten Fall degenerierte der B-Tree, was auch die spätere Performance deutlich herunterzog.Wenn zu einer Tabelle mehr als 10 % der bereits vorhandenen Datensätze hinzugefügt werden, macht es Sinn, die der Tabelle zugeordneten Zugriffswege (d.h. Index-Dateien) zu entfernen und nach dem Hinzufügen der Datensätze neu zu erstellen.
Gut, das ist 30 Jahre her, hat aber heute sicher noch ein gewisses Mass an Wahrheit.
Die andere Frage ist, brauchen wir Index-Dateien für SQL-Tabellen? Für einen Primary oder Unique Key auf jeden Fall, aber ansonsten? Unter Clipper und den Xbase++-DBEs ist das Positionieren in einer Datei sehr aufwändig, wenn kein Index existiert. SQL als Sprache ist aber auf die Ausführung solcher Ad-hoc-Queries optimiert (darum heisst es ja auch "Structure Query Language").
Habt Ihr mal geprüft, welche Eurer Index-Dateien wirklich erforderlich sind, bzw. wie lange eine Abfrage dauert, wenn ihr den zugrundeliegenden Index mal entfernt? (Der Query-Optimizer der meisten SQL-Server schaut sich nämlich die existierenden Index-Dateien an, bevor er richtig loslegt und Daten sucht).
Es ist natürlich auch möglich, dass die ISAM-Emulation ohne Zuordnung einer Index-Datei nicht will, das kann ich mangels Erfahrung nicht beurteilen. Aber selbst dann sollte bei Lade-Vorgängen - soweit möglich - auf die Verwendung von Index-Dateien verzichtet werden.