nicht angemeldet
Hallo Kess,
erstmal vielen, vielen Dank für diese ausführliche Antwort.
Eine Frage vorweg:
Wie kommt man zu solchem (Detail)Wissen?
Studium, Berufserfahrung, Privatvergnügen?
Kann man ja richtig neidisch werden ;-)
Macht es Sinn, eine Datenbank bis in die letzten Details zu normalisieren?
Es kommt darauf an ;-)
Ich habs befürchtet, allgemeingültige Aussagen wird man in diesem Bereich wohl nicht erhalten können :-(
Darum gilt im Allgemeinen: Je kleiner die Tabelle, desto weniger Sinn macht eine Normalisierung.
Kleines Beispiel aus dem Projekt:
Ich habe eine Tabelle AKTIEN, in der zu beliebigen Wertpapieren ca. 10 Daten gespeichert werden.
Unter anderem kann sich eine Aktie in verschiedenen Indices (DAX, NEMAX, ...) befinden, wobei die Anzahl der möglichen Indices auf 10 beschränkt ist.
Also ein typischer Fall einer N:M-Beziehung, die nach der Theorie 3 Tabellen erfordert:
1. AKTIE (id, ...)
2. INDEX (id, name)
3. AKTIE_INDEX (aktien_id, index_id)
Wie kann ich jetzt sowas performanter auf zwei Tabellen beschränken?
Die INDEX-Tabelle wegschmeissen und den INDEX-Namen bei AKTIE-INDEX speichern?
Oder, ganz anders, die INDEX-IDs in der AKTIEN-Tabelle in einem Feld mit Trennzeichen speichern und dafür AKTIEN_INDEX einstampfen? (wahrscheinlich dämlich?!)
Vor jedem groesseren Datenbankdesign sollte man sich ueberlegen, welche Daten in welchen Prozessen verarbeitet werden. Wird Wert auf eine leichte Pflege gelegt oder Wert auf Performance? Wie lauten die wichtigsten SQL-Statements? Wie sehen die Arbeitsablaeufe aus? Haeufige Abfrage und wenig "Bewegung" in den Daten selbst? Oder permanante Datenaenderungen? usw.
All diese Fragen spielen eine Rolle beim Datenbankdesign. Erst wenn der Anforderungskatalog mit Prioritaetenliste steht und eine vollstaendige (!) Beschreibung der Daten vorhanden ist, sollte das eigentliche DB-Design beginnen.
In der Praxis sieht es oft anders aus, was dann schnell zu Beschwerden ueber lahme DB-Server fuehrt und tatsaechlich fast immer am unpassenden Design liegt.
Welche Auswirkungen auf das Design hätten denn folgende Vorgaben:
Prio 1: Performance
Prio 2: Pflege
Viele (!!) Abfragen und eine konstante Zuwachs- bzw. Änderungsrate, dabei fast immer komplexe SELECT-Statements über mehrere Tabellen.
Daher gilt: Spalten fester Länge an den Anfang, Varchar-Spalten ans Ende der Tabelle.
Haeufiger benoetigte Spalten nach vorne, selten benoetigte Spalten ans Ende.
Super-Hinweis, wäre mir selber nie in den Sinn gekommen, das die Feldreihenfolge so grossen Einfluss haben kann.
Damit lässt sich bestimmt einiges optimieren.
Je genauer die noetige Laenge der Felder abgeschaetzt wird, desto weniger Platz wird unnoetig verschwendet und desto mehr Rows einer Tabelle passen in eine Page. Bei der Abfrage jeweils nur eines einzigen Satzes aus einer Tabelle ist dies irrelavent. Werden aber grosse Bereich der Tabele abgefragt, dann sind kuerzere Saetze in sofern interessant, dass das DBMS weniger Pages einlesen muss.
OK, dann werd ich unsere Redakteure mal ein wenig mit solchen Abschätzungen belästigen ;-)
Puh, das sind nur drei beispiele. Daneben gibt es noch tausend Dinge, die Performance kosten koennen. Datenbanktuning gehoert in den Bereich DB-Administration und der ist nicht ohne Grund ein eigener Beruf. Ein Blick in die Doku und besonders in den Abschnitt Tuning ist imho immer noch die beste Informationsquelle.
Ich seh schon, da wollen noch einige Dokus gewälzt werden!
Trotzdem nochmals herzlichen Dank für deine Anregungen.
Viele Grüsse
Stephan