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