DB-Konzeption lieber zwei Tabellen oder eine breite?

[Der Herr B]

Hallo,
ich habe gelesen (und auch mit anderen Projekten die Erfahrung gemacht), dass breite Tabellen (insbesonere über 8000 Bytes) auf Kosten der Performanz gehen und man logische Datensätze auf mehrere Tabellen aufteilen sollte.
Hier geht es zunächst um zwei Tabellen (eines Datensatzes mit insgesamt 3 Tabellen) mit jeweils etwa 100 Feldern und jeweils etwa 1000 Bytes Breite. Es fallen sofort 250.000 Datensätze an und monatlich kommen 100.000 dazu.
Ggf. können noch einige Felder (100? = 1000 Bytes?) in der Zukunft hinzukommen.
Mein Problem sind Update-Kommandos über einen Bestand von 100.000 Datensätzen, wenn zwei Felder darin vorkommen, die in verschiedenen Tabellen liegen. Die beiden Tabellen sind bisher mit 3 Schlüsselfeldern (IDNr, Datum, ProjektNr) und einzelnen nicht gruppierten Indexen verknüpft. So ein Update-Kommando dauert 30 Minuten. Wenn die Quell- und Zielfelder in einer Tabelle liegen, dauert es nur 1 Minute!
Die Updates beinhalten als Quellwerte Summenbildung über Gruppen und einige Joins in Views.
Ich denke, der Vorteil einer Kombination der beiden Tabellen liegt auf der Hand,
zumal auch einigeIndexe eingespart werden können.
Einen Test durchzuführen kostet mich sehr viel Zeit, denn ich müsste im positiven Fall ja noch die bisherigen Entwicklungen umbauen.
Mein Wochenende habe ich jedenfalls schon dafür verplant:-)
Kann mir jemand bitte einen Tipp geben. Welche Erfahrung habt Ihr gemacht?
Vielen Dank im Voraus!
Alleinkämpfer Rambo:-)

[Andreas Kosch]

Hallo,

die Frage, welchen Sinn 1:1-Tabellen machen, hängt von den Faktoren Datenbankgröße, RAM-Ausbau und Anzahl der Spalten, die sehr häufig abgefragt werden ab. Angenommen, die Tabelle enthält sehr viele Datensätze, wobei in der Regel immer nur eine kleine Anzahl der gleichen Spalten abgefragt wird. In diesem Fall ist die Aufteilung in 2 Tabellen sinnvoll, da die "Haupttabelle" mit hoher Wahrscheinlichkeit vollständig in den Datenbank-Cache passt. Wenn irgendwann einmal die "fehlenden" Spalten aus der anderen Tabelle nachgeladen werden müssen, ist die Nebenwirkungen verkraftbar. Dieses Szenario geht davon aus, dass SELECT-Abfrage auf die "Hauptspalten" deutlich läufiger ausgeführt werden als die sonstigen Abfrage oder Updates.

...3 Schlüsselfeldern (IDNr, Datum, ProjektNr) und einzelnen nicht gruppierten Indexen verknüpft.

Ein zusammengesetzter Index ist in diesem Fall immer von Nachteil. Im Idealfall reicht ein CLUSTERED INDEX aus, wobei der Primärschlüssel nur aus einer INT-Spalte besteht, deren Wert später niemals geändert werden muss. Der GAU tritt ein, wenn eine der Spalten des zusammengesetzten Schlüssels geändert wird, denn in diesem Fall wird ja das "Verbindungsglied" zwischen den beiden Tabellen geändert.

So ein Update-Kommando dauert 30 Minuten.

Wenn der Datenbank-Server mehrere CPUs bzw. Kerne hat, ist in diesem Fall nur ein einziger Kern unter Last oder ist die Last relativ gleichmäßig verteilt?

[Der Herr B]

Vielen Dank für die Antwort Herr Kosch,
(1) die Spalten in der Tabelle werden etwa gleich häufig verwendet. Ich würde mir Entwicklungsaufwand sparen, wenn ich also eine Tabelle mit 200 Spalten verwende. Das werde ich tun.
(2) Wenn ich einen Index auf mehrere Spalten verwende, wird der Index auch dann genutzt, wenn ich in einem JOIN mal nur mit einer Spalte des Schlüssels verknüpfe?
(3) Ich denke die Vollauslastung des Systems tritt auf, weil der SQL Server nicht alleine auf dem Server läuft sondern ausserdem noch einige WebServer.
Die 30-minütige Killer-Abfrage (Update-Join mit Summierung und Gruppierung) war wahrscheinlich nur falsch geschrieben.
Dasselbe Ergebnis liefert jetzt eine Stored procedure mit Schleife in 1 Minute.
Ich hoffe, dass die Anwendung so besser läuft.
Vielen Dank

[Andreas Kosch]

Hallo,

(2) Wenn ich einen Index auf mehrere Spalten verwende, wird der Index auch dann genutzt, wenn ich in einem JOIN mal nur mit einer Spalte des Schlüssels verknüpfe?

Nur dann, wenn von links nach rechts keine der zusammengesetzten Spalten im WHERE-Kriterum übersprungen wird. Dies bedeutet, dass die ganz links stehende Spalte immer im Spiel sein muss, damit der Index vom Optimizer ausgewählt werden kann.