Aruba die 2.te

[BenderD]

... es gibt zwei Nachteile:
- aus diesem Ansatz resultieren mehr wartbare Zugriffspfade
- diese Indexe komplizieren die Tätigkeit des Query Optimizers mehr als sie nützen (deshalb hat der die auch früher ignoriert)

D*B

[Fuerchau]

Wobei ab V7R1 diese LF's (calculated Indizes) mittels Where-Klausel genau getroffen werden müssen.
Man muss sich also eine Select/Omit-LF ansehen, aus den Select/Omit's einen where stricken und dann hoffen, dass der Optimizer den Index dann nimmt.
Bei calculated Indizes ist es insofern einfacher als das man die Where-Klausel aus dem Index direkt entnehmen kann.
Sobald man aber die Where-Klausel ergänzt kann es sein, dass der Index wieder ungünstig wird.

Was die LF-Joins angeht so sind diese meist nicht SQL-konform.
Bei SQL regelt man dies mit "Create View", das ist wesentlich flexibler.
Per View filtert man auch direkt auf die Daten.
Views haben den gewaltige Vorteil, es wird keine Index-Maintenance benötigt.
Im Gegensatz zu Indizes, die halt Wartungszeit kosten, können beliebig viele Views verwaltet werden.

Und Multiformat-Joins werden von SQL nicht unterstützt.
Dies muss man selber per "Union-Select" als View oder native stricken, geht aber auch.