Ist es wirklich besser, normalisierte Tabellen zu verwenden?

Es kommt darauf an ... Tabellen zusammenzufügen ist von Natur aus langsamer als eine große Tabelle zu haben, die "vorher verbunden" ist, dh de-normalisiert. Durch Denormalisierung werden Sie jedoch Datenduplikation erstellen und Ihre Tabellen werden größer. Die Normalisierung wird als eine gute Sache angesehen, da sie Datenbanken erstellt, die "jede" Frage beantworten können. Wenn dies richtig ist, können Sie eine Auswahl erstellen, um zu Ihren Daten zu gelangen. Dies ist in einigen anderen Formen von DB nicht der Fall, und diese sind jetzt (meistens) historische Irrelevanzen, die normalisierte / relationale DB hat diesen Kampf gewonnen.

Zurück zu Ihrer Frage: Die De-Normalisierung, um Dinge schneller zu machen, ist eine gut akzeptierte Technik. Normalerweise sollten Sie Ihre Datenbank eine Weile laufen lassen, damit Sie wissen, was Sie entmagnetisieren und was Sie in Ruhe lassen sollten. Es ist auch üblich, die Daten in ihrer "korrekten" normalisierten Form zu belassen und Daten in eine Reihe von normalisierten Berichten zu übertragen Tabellen regelmäßig. Wenn dieser Prozess als Teil des Berichts selbst ausgeführt wird, sind die Daten immer auf dem neuesten Stand.

Als Beispiel für eine übermäßige Normalisierung habe ich DBs in der Vergangenheit gesehen, wo die Wochentage und Monate des Jahres in separate Tabellen herausgezogen wurden - Daten selbst wurden normalisiert - Sie können zu weit gehen.

Sie sollten etwas über die Unterschiede zwischen OLTP (Online-Transaktionsverarbeitung) und OLAP (Online Analytical Processing) Datenbanken.

Kurz gesagt, Datenbanksysteme, die hauptsächlich mit Aufzeichnungstransaktionen (OLTP) befasst sind, sind normalerweise in einer normalisierteren Weise strukturiert, was die Datenduplizierung verringert und das Erstellen und Aktualisieren von Datensätzen auf Kosten einer optimierten Datenwiederherstellung erleichtert.

Datenbanksysteme, die sich mehr mit Datenabruf und -analyse (OLAP) befassen, sind normalerweise weniger normalisiert strukturiert, wodurch die Optimierung des Datenspeichers verloren geht, um die Abfrage- und Analysegeschwindigkeit zu maximieren.

Datenbanknormalisierung und Denormalisierung stehen im Mittelpunkt dieses Kompromisses.

Jeff schrieb darüber , gefolgt von einer hitzigen Diskussion. Es wird auch viel über SO diskutiert, z. was ist der bessere Datenbankentwurf mehr Tabellen oder mehr Spalten . Wie andere gezeigt haben, benutze den gesunden Menschenverstand und übertreibe dich nicht.

In meiner langjährigen Erfahrung mit Oracle OLTP Datenbanken, von denen einige sehr groß und beschäftigt sind, kann ich ehrlich sagen, ich kann mich nicht erinnern, jemals einen Fall gefunden zu haben, in dem "Denormalisierung für Leistung" wirklich war erforderlich. Ich habe jedoch viele Fälle gesehen, in denen jemand im Vorfeld entschieden hat, dass Denormalisierung angewendet werden sollte, weil sie Angst, Unsicherheit und Zweifel an potenziellen Leistungsproblemen haben. Dies wurde normalerweise ohne Benchmarking durchgeführt, und ich stelle fest, dass in der Tat keine Leistungsverbesserung erreicht wurde - aber der Code für die Datenpflege ist weitaus komplexer geworden, als er es gewesen wäre.

OLAP ist ein ganz anderes Tier, und dazu kann ich nichts sagen.

Diese Frage wiederholt sich zu oft. Der Hauptgrund dafür ist, dass SQL, die beliebteste Datenbanksprache mit einem großen Vorsprung, und all ihre populärsten Implementierungen das logische Tabellendesign mit dem physischen Tabellendesign verbinden.

Die ewige Antwort ist, dass Sie Ihre logischen Tabellen immer normalisieren sollten, aber die pragmatische Antwort wird durch die Tatsache kompliziert, dass die einzige Möglichkeit, bestimmte Optimierungen unter bestehenden SQL-Implementierungen zu implementieren, das physische Tabellendesign zu denormalisieren (an sich keine schlechte Sache) ) was bei diesen Implementierungen eine Denormalisierung Ihres logischen Tabellendesigns erfordert.

Kurz gesagt, es kommt darauf an. Manchmal ist eine Denormalisierung wichtig für die Leistung, aber wie bei allen anderen Leistungsmerkmalen sollten Sie messen, messen und messen, bevor Sie überhaupt daran denken, diesen Weg zu gehen.

Der Grund, warum bekannt ist, dass die Normalisierung die Performance beeinträchtigt, ist, dass Joins ziemlich teuer sind. Wenn in den Tabellen X- und M-Datensätzen in Tabelle Y N Datensätze vorhanden sind, dann erzeugt ein Join von X und Y eine temporäre Tabelle mit so vielen N * M Datensätzen. Obwohl es Optimierungstricks gibt, die die Datenbank verwendet, um nicht die gesamte Tabelle zu generieren, wenn sie nicht benötigt wird, muss sie dennoch alle Datensätze verarbeiten.

Denormalisierung ist der Prozess, bei dem Sie häufig verwendete Daten in einer einzigen Tabelle zusammenfassen, um die Leistung zu erhöhen, um eine gewisse Reinheit der Datenbank zu gewährleisten. Die meisten finden, dass es ein annehmbarer Handel ist, und gehen sogar so weit, das Schema zu entwerfen, das absichtlich denormalisiert ist, um den Zwischenschritt zu überspringen.

Die Leistung ist invers zu der Normalisierung, die auf RDBMS durchgeführt wird. Je normaler die Tabellen sind, desto geringer ist die Wahrscheinlichkeit für Fehler. Es gibt einen Punkt, an dem eine RDBMS-Leistung durch Denormalisierung beeinträchtigt werden kann, an dem Punkt, an dem alle Daten in einer Tabelle gespeichert sind.