So, nach einem erheiternden Stromausfall im Geschäft versuch ich mich hier mal wieder mit erfreulicheren Problemen
Eine generelle Formel gibt es für diese Frage (wie kann es anders sein) natürlich nicht. Es kommt auch ganz speziell auf das System an, sprich habe ich ein OLTP System mit vielen kleinen Transaktionen, oder betreibe ich ein Data Warehouse mit großen Batch Jobs und Ladeoperationen. Die beiden Systeme fordern komplett unterschiedliche Betrachtung des index Designs.
Oralce liefert zwei grobe Faustformeln die man hier beachten sollte. Zum einen ist ein INSERT oder UPDATE Statement ca. 3x so Resourcenintensiv mit einem Index, als ohne. Sprich wenn ich 3 Indizes auf einer Tabelle habe brauche ich fast 10x so viel Resourcen bei einem Insert. Ein DELETE braucht nicht ganz so viel, da der Leaf Block des Indexes nicht entfernt sondern nur als gelöscht markiert wird.
Dies führt wiederum zu dem Problem das Indizes immer größer und langsamer werden je mehr Bewegung in meiner Tabelle ist. Daher die zweite Fausformel: Wurden ca. 10% der Tabelle geändert oder gelöscht oder neu eingefügt, sollte der Index neu aufgebaut werden.
Anhand dieser beiden Kriterien muss man nun überlegen was für sein System das Beste ist. Für ein Datawarehouse mit zahllosen Inserts ist es zum Beispiel üblich den Index vor dem Import zu droppen und danach neu aufzubauen. Das beschleunigt den Import um ein vielfaches.
OLTP Systeme hingegen sind meist Abfrage lastig, weshalb auf Indizes niemals verzichtet werden kann. Oft bestehen Tabellen sogar nur aus reinen Index Strukturen (IOT`s) um den Zugriff weiter zu beschleunigen. hier fallen die wenigen Änderungen dann kaum ins Gewicht. Wer also ein OLTP System betreibt steht nicht vor der Frage ob er Indizes benutzt, sondern wie viele.
Also, wie schon gesagt, eine Fausformel gibt es dafür nicht, ich bin gerade in Webanwendungen immer sehr gut damit gefahren generell PK`s anzulegen und für Kreuztabellen (n:m) IOT`s zu verwenden. Ebenso wichtig ist es meiner Meinung nach alle FK Spalten mit Indizes zu belegen um Locks zu vermeiden. Das ist zwar in 9i nichtmehr so kritisch, kann aber dennoch nix schaden. Dann hab ich oft noch ein paar Unique Indizes für Spalten wie Username oder so, wenn ich als PK eine numerische ID habe. (Ich vermeide meist VARCHAR2 Felder als PK). Und ob weitere Indizes nötig sind wird im Testbetrieb ermittelt, wobei hier bei durchdachtem Tabellendesign so gut wie nie nachgebessert werden muss.
Im Datawarehouse Bereich würde ich dann eher auf Bitmap und Bitmap Join Indizes zurückgreifen, die werden nicht so groß und sind bei großen Datenmengen effizienter, ist aber wieder ein eigenes Kapitel da man bei Bitmap Indizes auch sehr viel Performance verlieren kann.
