Ist die Datenbanknormalisierung tot? [geschlossen]

Ich bin in der alten Schule aufgewachsen - wo wir gelernt haben, das Datenbankschema VOR der Geschäftsschicht der Anwendung zu entwerfen (oder OOAD für alles andere zu verwenden). Ich war ziemlich gut mit dem Entwerfen von Schemas (IMHO :) und normalisierte nur, um unnötige Redundanz zu entfernen, aber nicht, wenn dies die Geschwindigkeit beeinträchtigte. Aber meistens war es nicht so.

Mit dem Aufkommen einiger ORM-Frameworks wie Rubys ActiveRecord oder ActiveJDBC (und einiger anderer, an die ich mich nicht erinnern kann, aber ich bin mir sicher, dass es viele gibt) scheint, dass sie es vorziehen, einen Ersatzschlüssel für jede Tabelle zu haben, selbst wenn einige Primärschlüssel wie haben "E-Mail" - 2NF sofort brechen. Okay, ich verstehe nicht zu viel, aber es geht mir (fast) auf die Nerven, wenn einige dieser ORMs (oder Programmierer) nicht 1-1 oder 1-0 | 1 (dh 1 zu 0 oder 1) bestätigen. Sie schreiben vor, dass es einfach besser ist, alles als einen großen Tisch zu haben, egal ob es eine Tonne nulls "heutige Systeme können damit umgehen" hat, ist der Kommentar, den ich öfter gehört habe.

Ich stimme zu, dass Speicherbeschränkungen in direktem Zusammenhang mit der Normalisierung standen (es gibt auch andere Vorteile :), aber ist das Konzept der DB-Normalisierung in der heutigen Zeit mit billigem Speicher und Quad-Core-Computern nur den Texten überlassen? Üben Sie als DBAs noch die Normalisierung auf 3NF (wenn nicht BCNF :)? Ist das wichtig? Ist das Design eines "schmutzigen Schemas" gut für Produktionssysteme? Wie soll man die Normalisierung begründen, wenn sie noch relevant ist?

( Hinweis: Ich spreche nicht von den Stern- / Schneeflockenschemata von Datawarehouse, die Redundanz als Teil / Bedarf des Designs haben, sondern von kommerziellen Systemen mit einer Backend-Datenbank wie z. B. StackExchange.)

Ein Grund für die Normalisierung besteht darin, Datenänderungsanomalien zu entfernen, die von
ORMs normalerweise nicht unterstützt werden.

Ich habe viele Beispiele für von Hibernate entworfene Datenbanken, die gegen dieses Prinzip verstoßen:

• aufgebläht (Zeichenfolge wiederholt über 100 Millionen Zeilen)
• keine Nachschlagetabellen (siehe oben)
• kein DRI (Constraints, Keys)
• varchar gruppierte Indizes
• unnötige Verknüpfungstabellen (zB Erzwingen von 1..0: 1, wenn eine nullfähige FK-Spalte ausreichen würde)

Das Schlimmste, was ich gesehen habe, ist eine 1-TB-MySQL-Datenbank, die vielleicht 75-80% zu groß war

Ich würde auch vorschlagen, dass die Aussage "heutige Systeme können damit umgehen" für die meisten Mickey-Mouse-Systeme zutrifft. Wenn Sie skalieren, werden die heutigen Systeme dies nicht tun.

In meinem obigen Beispiel gab es keine Möglichkeit, Schlüssel zu refaktorisieren oder zu ändern oder Daten zu reparieren: Beschweren Sie sich lediglich über die Wachstumsraten der Datenbank und die Unfähigkeit, einen aussagekräftigen DW darauf aufzubauen

Es scheint, dass sie es vorziehen, einen Ersatzschlüssel für jede Tabelle zu haben, selbst wenn einige Primärschlüssel wie "E-Mail" haben - was 2NF völlig kaputt macht.

Ersatzschlüssel brechen nicht 2NF. 2NF sagt: "Wenn eine Spalte nur von einem Teil eines mehrwertigen Schlüssels abhängig ist, entfernen Sie diese Spalte in eine separate Tabelle."

Sie schreiben vor, dass es einfach besser ist, alles als einen großen Tisch zu haben, egal ob es eine Tonne Nullen hat

Das Vorhandensein mehrerer Spalten in einer Tabelle ist gültig, solange die Normalisierungsregeln eingehalten werden. Das Zusammenführen von Tabellen ohne Analyse ist nicht korrekt, wenn Sie die Vorteile von SQL und Normalisierung nutzen möchten.

Ich stimme zu, dass Speicherbeschränkungen in direktem Zusammenhang mit der Normalisierung standen. Relation Normal Forms ist ein mathematisches Konzept und hat nichts mit Speicher zu tun.

Durch die Normalisierung wird nicht nur Speicher oder Festplatte gespart, sondern auch die Integrität erhöht. Immerhin handelt es sich um ein hardwareunabhängiges mathematisches Konzept.

Einfaches Beispiel: Angenommen, Sie pflegen Schulinformationen wie folgt:

Rec 1: North Ridge High School, Kalifornien, USA

Rec 2: South Toronto Braves Gymnasium, Ontario, Kanada

Wenn Sie Ihr System fragen, wo sich Ontario befindet, können Sie feststellen, dass es sich in Kanada befindet. Wenige Tage später löschen Sie die 2. Zeile und stellen dem System die gleiche Frage, und Sie erhalten nichts. In diesem Beispiel, egal wie viel Speicherplatz oder Arbeitsspeicher oder CPU, erhalten Sie keine Antwort.

Dies ist eine Anomalie, die normalisierende Beziehungen verhindert.

Bearbeiten: Das Wort "Toronto" wurde in "Ontario" geändert (siehe Kommentar unten).

Je mehr Dinge sich ändern, desto mehr bleiben sie gleich. Es gab schon immer faule Entwickler, die Abstriche machten oder einfach nicht wussten oder Best Practices befolgen wollten. Meistens schaffen sie es mit kleineren Anwendungen.

Früher hat es COBOL-inspirierte Datenstrukturen in frühes RDBMS oder in das gottesfürchtige Durcheinander gebracht, das dBase war. Jetzt sind es ORMs und "Code-First". Letztendlich sind dies alles nur Möglichkeiten für Menschen, die versuchen, die Königswirkung eines funktionierenden Systems zu finden, ohne Zeit damit zu verschwenden, über das nachzudenken, was Sie tun möchten und müssen. In Eile zu sein war schon immer ein Problem und wird immer ein Problem sein.

Für diejenigen, die den gesunden Menschenverstand (und das Glück) haben, sich die Zeit für das richtige Design zu nehmen, ist das Datenmodell immer der logischste Ausgangspunkt. In der Datenbank werden Informationen zu den Dingen (materiell und immateriell) gespeichert, die für Ihr Unternehmen von Bedeutung sind. Was Ihr Unternehmen interessiert, ändert sich viel weniger schnell als das, was Ihr Unternehmen betreibt. Aus diesem Grund ist Ihre Datenbank im Allgemeinen viel stabiler als Ihr Code.

Die Datenbank ist das rechtmäßige Fundament eines jeden Systems, und wenn Sie sich die Zeit nehmen, um Ihre Fundamente richtig zu legen, werden Sie auf lange Sicht unweigerlich davon profitieren. Dies bedeutet, dass die Normalisierung für jede OLTP-Anwendung immer ein wichtiger und nützlicher Schritt ist.

Ich stimme zu, dass Speicherbeschränkungen in direktem Zusammenhang mit der Normalisierung standen ...

Speicherbeschränkungen spielen immer noch eine Rolle. Quantität ist kein Problem, Geschwindigkeit ist.

• CPUs werden im Moment nicht schneller (wir bekommen mehr Kerne, keine Zyklen pro Sekunde)
• Moderne CPU-Architekturen versuchen, die Geschwindigkeitsbegrenzung zu überwinden, indem für jeden Prozessor ( NUMA ) ein separater Speicher bereitgestellt wird .
• Die Cachegrößen auf dem Die wachsen nicht mit dem Hauptspeicher vergleichbar.
• Der Speicherdurchsatz ist nicht so hoch, wie die meisten Leute erwarten. QPI liegt im Bereich von 25 GB / s.

Einige dieser Gründe wurden in Wann sollte TINYINT über INT verwendet werden? was Sie vielleicht nützlich finden. Ich würde auch vorschlagen, den Possen von @ThomasKejser ( Blog ) aus dem SQLCAT-Team zu folgen, da diese dazu neigen, die Datenbankleistung zu verbessern. Der jüngste Beitrag über die Auswirkungen von CPU-Caches und Speicherzugriffsmustern und die SQLBits-Präsentation über relationale Modellierung für extreme DW-Skalierungen sind gute Beispiele.

Meiner Meinung nach geht es immer noch nur um das Gleichgewicht zwischen Normalisieren und De-Normalisieren . Ich stimme voll und ganz zu, dass ORM-Frameworks lediglich Ansätze sind, um Dinge zu erledigen, aber ich glaube nicht, dass diese Frameworks den Trend zur De-Normalisierung auslösen .

Es ist immer noch die Debatte, bei der Sie Zeiteffizienz oder Raumeffizienz wünschen. Zu dem Zeitpunkt, an dem die Relational Database-Theorie zur Sprache gebracht wird, ist der Plattenspeicher teuer, die Leute wollen offensichtlich nicht so viel Geld dafür ausgeben, deshalb sind relationale Datenbanken zu diesem Zeitpunkt diejenigen, die inmitten von Widrigkeiten fest stehen

Heutzutage sind die Dinge ganz anders, die Lagerung ist sehr, sehr billig. Es ist also klar, dass wir im Vergleich zu früher mehr Redundanz tolerieren können. Dies ist auch der Grund, warum der BIG_TABLE-Ansatz erschienen ist. Um mehr Zeiteffizienz zu erreichen, muss die Raumeffizienz geopfert werden.

Aber Big-Table-Ansatz ist auch nicht das Ende der Geschichte, es ist immer noch das Gleichgewicht zwischen Zeit und Raum, in Bezug auf die zu verwaltenden PB-Volumendaten, einige Entwickler begannen auch, das Gleichgewicht zurück zur Raumeffizienz zu suchen, deshalb gibt es Es werden Arbeiten durchgeführt, um einige Daten in BIG-TABLE-ähnlichen Strukturen zu normalisieren.

Mit einem Wort, der Normalisierungsansatz ist nicht definitiv tot, wird aber im Vergleich zu den alten Zeiten definitiv übersehen.

CJ Date beantwortet hier Ihre Frage - das Normalisierungsvideo (vorab) ist kostenlos.

http://shop.oreilly.com/product/0636920025900.do

Die kurze Antwort: Normalisierung ist die mathematisch korrekte Vorgehensweise. Wenn Sie nicht richtig normalisieren, ist Ihr Datenmodell einfach falsch.