Hallo,

Bei nativen Zugriffen muss ich mir leider VORHER über LF's Gedanken machen.
Bei SQL's meistens HINTERHER oder sogar erst, wenn's beim Kunden nicht so performant ist (weil der ja mehr Daten hat).
Auch bei SQL sollte man sich vorher (und nicht erst hinterher) Gedanken über die Zugriffswege machen, um von vornherein Performance-Problemen soweit wie möglich aus dem Weg zugehen.
(Proaktive Indexing Strategie)

Es kann natürlich vorkommen, dass aufgrund der unterschiedlichen Datenkonstellationen oder unterschiedlichen Release-Ständen auf Echt- und Test-Maschinen verschiedene Zugriffswege verwendet werden. Im Extremfall kann das sogar dazu führen, dass auf der Test-Maschine ein Zugriffsweg gefunden wurde, während der Optimizer sich auf der Echt-Maschine für einen Table-Scan entscheidet.
(Reaktive Indexing Strategie)

Beim Einsatz von SQL sollte man halbwegs verstehen, wie die Query Engines arbeiten und wann welche Query Engine eingesetzt wird. Viele Performance-Probleme kommen außerdem daher, dass SQL-Statements so gestaltet werden, dass der Optimizer überhaupt keine Chance hat einen Index zu verwenden. (z.B. Zugriff über relative Record-Nr. oder die Verwendung von skalaren Funktionen auf der linken Seite der Vergleichsoperatoren in den Where-Bedingungen)

Mit zunehmendem Einsatz von SQL, sind die Zeiten, in denen kein Datenbanken-Administrator notwendig war vorbei. Selbst IBM empfiehlt inzwischen, dass jemand regelmäßig ein Auge auf die (SQL-)Performance hat, der gegebenenfalls neue Zugriffswege (geschlüsselte logische Dateien oder SQL Indices) anlegt, bzw. nicht mehr benötigte Zugriffswege löscht. Es gilt zu bedenken, dass jeder zusätzliche Zugriffsweg Performance kostet, d.h. bei jedem Insert, Update oder Delete eines Datensatzes in der zugrundeliegenden physischen Datei (oder SQL Tabelle) müssen alle Zugriffswege aktualisiert werden.


Birgitta