Und wenn die Views zu komplex werden und dadurch das Erstellen der View zu lange dauert, dann erstellt man eine Tabelle, die dann wie die View genutzt wird (rein lesend).
Wie machst du das dann in der Praxis? Wird diese Zusatztabelle gefüllt, wenn die eigentlichen Tabellen gefüllt werden? Mit triggern usw? Oder wird diese Tabelle alle Nase lang mal neu erstellt/aktualisiert?
Wir haben (wenn sowas tatsächlich erforderlich ist) dann entsprechende Prozesse, die zu definierten Zeitpunkten die vorhandene Tabelle wegwerfen und per
Code:
Create table as select * from a,b,c,d,e,... where a.id = b.id...
neu erstellen. Dahinter läuft dann ein entsprechendes Script für die Indexerstellung, Statistiken...
Ein Truncate Table mit anschließender Neubefüllung kann es natürlich auch tuen. Gerade bei sehr großen Datenmengen kann es aber deutlich schneller werden, wenn man eine "indexlose" Tabelle befüllt und die Indexerstellung erst nach der Befüllung vornimmt. Die Indexpflege beim Befüllen kann, je nach Datenmenge, auch schonmal (gefühlt) Wochen dauern.
Es kann aber auch passieren, dass von einem Programm die Tabelle geleert wird und dann vom Programm die "Basisdaten" in diese Tabelle geschrieben werden und nachfolgende Prozesse mit den "Basisdaten" dieser Tabelle (und ggfls. weiteren Tabellen) Berechnungen durchführen, um diese dann in weiteren Spalten der Tabellen abzulegen.
Weitere Prozesse können dann auf die hier abgelegten "Basisdaten" + "Zusatzdaten" zugreifen und ggfls. weiter Ergebnisse in weiteren Spalten ablegen.
In den Systemen, die ich habe kennenlernen dürfen, haben die kleineren Tabellen sowas um die 30 Mio. Sätze gehabt, die größeren um die 150 bis 200 Mio.
Aber die Regel, die einem klar sagt, wie man soetwas macht, gibt es eigentlich nicht. Es kommt doch sehr auf die Datenmenge, die "Eigenheiten" des genutzten Datenbanksystems und letztlich nicht unerheblich auf die Hardware an, auf der der "ganze Spaß" läuft.
Zitat von
Aurelius:
Es ist natürlich richtig, dass man durch Normalisierung etc. Einbußen in der Performance bekommt. Allerdings nehme ich persönlich sowohl im Datenbankdesign als auch im Quelltext Peformanceverluste (sofern sie im Rahmen bleiben und es keine zeitkritische Anwendung ist) in Kauf, solange dadurch das System verständlich und leicht wartbar/erweiterbar bleibt.
Dies halte ich für eine wesentliche Aussage. Mir ist noch kein System "in Finger" gekommen, an dem Anwender im Dialog "live" gearbeitet haben und bei dem aus Performancegründen eine Denormalisierung erforderlich war. An eine gezielte Denormalisierung denke ich erst, wenn es darum geht, die Laufzeit von Wochen auf Tage zu reduzieren.
Auch wenn ich ggfls. auf denormalisierte Daten schneller zugreifen kann, als auf normalisierte Daten, so darf ich den (Zeit)Aufwand für die Denormalisierung und deren Konsistenzhaltung nicht vergessen.
Habe ich in einem System mit 40000, 50000 Kunden und den zugehörigen Nachschlagtabellen ein Performanceproblem, so habe ich sicherlich ein Problem, dass nicht durch Denormalisierung sinnvoll gelöst wird, sondern eventuell nur eine schlecht konfigurierte Datenbank oder eine umständliche und resourcenfressende Umsetzung der Geschäftslogik.
Viele Performanceprobleme, die ich habe lösen müssen, lagen weder an der Normalisierung der Daten, noch an der Hardware, sondern einfach nur an äußerst umständlicher Umsetzung von Abfragen.