Index und Index bei SQL-Tabellen

alles was zunächst nicht kategorisierbar ist

Moderator: Moderatoren

Antworten
georg
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2823
Registriert: Fr, 08. Feb 2008 21:29
Hat sich bedankt: 95 Mal
Danksagung erhalten: 13 Mal

Index und Index bei SQL-Tabellen

Beitrag von georg »

Guten Tag,


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):
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.
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.

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.
Liebe Grüsse aus der Eifel,

Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: Index und Index bei SQL-Tabellen

Beitrag von Jan »

Georg,

das Problem liegt ja ganz woanders. Wenn ich die PG-ISAM nutze dann mach ich das ja, weil ich den Code mit den DB-Funktionen weiter nutzen möchte/muß. Klar kann ich den nach und nach auf SQL migrieren, aber das ist in manchen Bereichen sicher mit einer kompletten Neuentwicklung verbunden. Von daher sind die alten Indizes (erstmal) notwendig. So lange bis man eine passende SQL-Lösung gefunden und entwickelt hat.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
georg
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2823
Registriert: Fr, 08. Feb 2008 21:29
Hat sich bedankt: 95 Mal
Danksagung erhalten: 13 Mal

Re: Index und Index bei SQL-Tabellen

Beitrag von georg »

Hallo, Jan -


ein Thema ist das Upsize. Wenn während des Upsize Index-Dateien vorhanden sind, hat das einen Einfluss auf die Performance.
Liebe Grüsse aus der Eifel,

Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: Index und Index bei SQL-Tabellen

Beitrag von Jan »

Georg,

ja, schon klar. Aber ich Upsize ja nur, wenn ich ISAM weiter nutzen will/muß. Und dann brauch ich auch die alten Indizes.

Es ging mir nur um Deine Aussage das man sich überlegen sollte, ob man die alten Indizes wirklich noch benötigt.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Antworten