Relationale Datenbanken sind darauf ausgelegt, viele Zeilen pro Tabelle zu speichern. Es gibt eine ganze Reihe von Mechanismen, um große Tabellen zu erleichtern, wie zum Beispiel:
- Indizes für beliebige Kombinationen von Feldern zur Beschleunigung der Suche
- Seiten-Caching, damit häufig verwendete Seiten im Speicher bleiben
- Vertikale Partitionierung (spaltenförmige Datenbanken) zur weiteren Beschleunigung von Anfragen
- Fortgeschrittene Algorithmen wie Hash Joins und Group Bys (zumindest in anderen Datenbanken als MySQL)
- Verwendung mehrerer Prozessoren und Datenträger zur Verarbeitung von Abfragen
Es gibt eine Sache, die schwieriger ist, wenn Daten in eine einzelne Tabelle gestellt werden, und das ist die Sicherheit. Und tatsächlich ist dies unter manchen Umständen ein Hauptanliegen und erfordert im Grunde, dass die Daten in einer separaten Tabelle abgelegt werden. Diese Anwendungen sind selten und weit verstreut.
Um ein Beispiel dafür zu geben, wie schlecht das Speichern von Daten in mehreren Tabellen sein kann, stellen Sie sich vor, dass Sie in Ihrem System einen Datensatz pro Unternehmen haben und ihn in einer Tabelle speichern. Dieser Datensatz speichert Informationen über das Unternehmen – so etwas wie Name, Adresse, was auch immer. Anruf besteht aus 100 Bytes an Informationen.
In Ihrem Schema gibt es für jedes "Unternehmen" eine separate Tabelle, also eine Zeile pro Tabelle. Dieser Datensatz befindet sich auf einer Datenseite. Eine Datenseite könnte 16 kByte groß sein, Sie verschwenden also etwa 15,9 kByte, um diese Daten zu speichern. Das Speichern von 1000 solcher Aufzeichnungen belegt 16 Mbyte statt etwa 7 Seiten (112 Kbyte). Das kann eine erhebliche Leistungseinbuße sein.
Darüber hinaus berücksichtigen Sie bei mehreren Tabellen nicht die Herausforderungen, alle Tabellen zu pflegen und die Korrektheit der Daten in den verschiedenen Tabellen sicherzustellen. Wartungsaktualisierungen müssen auf Tausende von Tabellen angewendet werden, anstatt auf eine Handvoll.
