Firebird - Temporärer Index

[MyRealName]

Du kannst es vllt in eine temporäre Tabelle (deren Inhalt nur für eine Transaction oder Connection sichtbar ist) reinschrieben, die den Index hat, den Du brauchst

[peterbelow]

Zitat:

Zitat von lxo (Beitrag 1523551)

Wie kann man denn für eine View einen Index erstellen?

Ich muss gestehen dass ich nur mit Oracle Erfahrung habe und das ist auch schon etliche Jahr her. Oracle hat sog. "materialized views" auf denen man auch Indizes anlegen kann wenn mich mein Vergessnis nicht täuscht.

[lxo]

Ich mach den Index jetzt einfach generell rein und fertig.
Andere Statements leiden darunter nicht und auch Massen-Inserts sind nicht langsamer. Also schadet der nicht und für meine Procedure hilft er ungemein. :thumb:

[MyRealName]

Zitat:

Zitat von peterbelow (Beitrag 1523572)

Zitat:

Zitat von lxo (Beitrag 1523551)

Wie kann man denn für eine View einen Index erstellen?

Ich muss gestehen dass ich nur mit Oracle Erfahrung habe und das ist auch schon etliche Jahr her. Oracle hat sog. "materialized views" auf denen man auch Indizes anlegen kann wenn mich mein Vergessnis nicht täuscht.

Eine View in Firebird hat keine Indizes.

[TBx]

Zitat:

Zitat von lxo (Beitrag 1523576)

Ich mach den Index jetzt einfach generell rein und fertig.
Andere Statements leiden darunter nicht und auch Massen-Inserts sind nicht langsamer. Also schadet der nicht und für meine Procedure hilft er ungemein. :thumb:

Das ist nach meiner Meinung nach auch die einzig sinnvolle Lösung.

[Blup]

Normalerweise kostet ein Index nicht so viel, dass sich weitere Optimierung lohnen würde.
Aber wenn wenige bestimmte Datensätze eine besonderer Bedeutung haben, kann man sich z.B. als Ersatz für ein Boolean-Feld auch eine Hilfstabelle anlegen, die nur die ID dieser Datensätze enthält.
Die kann z.B. einfach durch einen Trigger gefüllt werden, wenn Datensätze eingefügt oder geändert werden.
Eine View stellt das Ergebnis einer Abfrage auf die Hilfstabelle mit Left-Join zur Haupttabelle dar.

[IBExpert]

kosten vom zusätzlichen index entstehen nur beim schreiben der datensätze via insert/update/delete, wenn da also nicht endlos drauf geschrieben wird, ist der mehraufwand vernachlässigbar. soll aber nicht heissen, das man bei einer tabelle mit 100 feldern einfach mal auf verdacht 100 einzelfeld indizes ascending und zur sicherheit noch 100 einzelfeld indizes descending anlegt. das wird man auf jeden fall merken und ist offensichtlicher mumpitz.

Index auf views gibt es nicht, wurde hier aber ja auch schon korrekt erkannt.

wenn es sinnvoll ist, kann man sich in der ibexpert demo db mal anschauen, wie man eine materialized view nachbilden kann (ist in der datenbank als V_TOP100SALES eingebaut), dessen daten zB großen datenmenge zusammenfassen, der aber schreibend nur on demand maximal ein mal pro minute neu berechnet wird, hatte ich auch in unseren ibexpertise youtube stammtisch videos mal erklärt.

Das oracle konzept des materialized views hatte einen kunden schon mal wegen der einstellung on commit statt on demand in extreme probleme gebracht (die hatte den view deklariert, wir haben da nur jede nacht ca 10000 inserts/updates/deletes gemacht die von einer firebird db kamen und aufgrund der langen leitung zum oracle server sehr oft committed werden mussten, war mit odbc und ibescript zwischen firebird und oracle ganz einfach, bis irgendjemand von denen da ein halbes jahr später den view angelegt hatte, der dann parallel 10000 neuberechnungen ausgelöst hatte und morgens stundenlang keiner mehr arbeiten konnte. da wir nur nachts daten senden, hatte der damit tagsüber noch kein problem ....

Index aktivieren/deaktivieren geht zwar, frisst während dieser zeit zum aktivieren aber sehr viel I/O Last und je nach fb version und hardware kann das eine doofe idee sein

meine tip wie schon von dir gewählt weg: leg den index an und lass den an, wen störts ...