Wie wirkt sich die Normalisierung einer Datenbank auf die Ressourcen aus?

Question

Wenn Sie eine Datenbank von einem relativ un-normalisierten Formular nehmen und es normalisieren, was, wenn überhaupt, Änderungen in Ressourcenauslastung könnte man erwarten?

Zum Beispiel bedeutet Normalisierung oft, dass mehr Tabellen aus weniger erstellt werden, was bedeutet, dass die Datenbank jetzt eine höhere Anzahl von Tabellen hat, aber viele davon sind recht klein, so dass die oft verwendeten besser in den Speicher passen. Die höhere Anzahl an Tabellen bedeutet auch, dass mehr Joins erforderlich sind, um die extrahierten Daten zu erhalten. Daher würde man von der höheren Anzahl an Joins, die das System benötigt, eine gewisse Auswirkung erwarten.

Also, welche Auswirkungen auf die Ressourcennutzung (dh was wird sich ändern) hat normalisieren eine nicht-normalisierte Datenbank?

---

Edit: ein wenig Kontext hinzuzufügen, ich habe eine vorhandene Datenbank mit über 300 schreckliche Tabellen (dh Vermächtnis.). Etwa die Hälfte der Daten ist TEXT und die andere Hälfte ist entweder Char-Felder oder Ganzzahlen. Es gibt keinerlei Beschränkungen. Der Grund, den ich stelle, besteht in erster Linie darin, mehr Informationen zu bekommen, um andere davon zu überzeugen, dass sich Dinge ändern müssen und dass es keine Abnahme der Leistung oder Wartbarkeit geben wird. Leider müssen diejenigen, die ich überzeugen muss, gerade genug über die Leistungsvorteile einer de-normalisierten Datenbank wissen, um die Normalisierung so weit wie möglich zu vermeiden.

Answer 1

Dies kann nicht wirklich allgemein beantwortet werden, da die Auswirkungen schwer abhängig von den Besonderheiten der Datenbank in Frage und die Apps, die es verwenden.

So erklärte man im Grunde die allgemeinen Erwartungen in Bezug auf die Auswirkungen:

1. Gesamtspeicherbedarf für die Lagerung, wie redundante Daten
2. CPU benötigt steigen möglicherweise entfernt wird untergehen sollte, wie Macht abfragt werden teurer (Beachten Sie, dass Abfragen in einer normalisierten Datenbank in vielen Fällen schneller sind, auch wenn sie komplexer sind, da es mehr Optimierungsoptionen für die Abfrage-Engine gibt)
3. Entwicklungsressourcen e braucht könnte steigen, als Entwickler könnte Notwendigkeit aufwändiger Abfragen erstellen (Aber auf der anderen Seite, müssen Sie weniger Entwicklungsaufwand Datenintegrität zu erhalten)

die einzige wirkliche Antwort So ist die übliche : es kommt darauf an;)

Hinweis: Dies setzt voraus, dass es sich um vorsichtige und absichtliche Denormalisierung handelt. Wenn Sie auf die beziehen ‚werfen nur einige Tische zusammen als Daten zusammen kommt‘ Ansatz Weg gemeinsam mit unerfahrenen Entwicklern, ich die Aussage riskieren würde, dass Normalisierung Ressourcenbedarf auf allen Ebenen reduzieren;)

---

Edit: den spezifischen Kontext von cdeszaq hinzugefügt betrifft, so würde ich ‚Viel Glück Ihr Punkt durch immer‘ sagen;)

oviously, mit mehr als 300 Tabellen und ohne Einschränkungen(), die Antwort auf Ihre Frage! definitiv "Normalisierung wird Ressourcenbedarf auf allen Ebenen reduzieren" (und wahrscheinlich sehr wesentlich), aber:

Refactoring solch ein Chaos wird ein großes Unternehmen sein. Wenn nur eine App diese Datenbank nutzt, ist es schon furchtbar - wenn es viele gibt, könnte es ein Albtraum werden!

So, selbst wenn Normalisierung wesentlich Ressourcenverbrauch auf lange Sicht reduzieren würde, könnte nicht die Mühe wert sein, abhängig von den Umständen. Hier geht es vor allem um den langfristigen Handlungsspielraum - wie wichtig ist diese Datenbank, wie lange wird sie genutzt, gibt es in Zukunft mehr Apps, ist der laufende Wartungsaufwand konstant oder steigt etc. ...

ignorieren sie nicht, dass es ein laufendes System ist - auch wenn es hässlich und schrecklich ist, nach Ihrer Beschreibung es ist (noch) nicht gebrochen ;-)

Answer 2

Zum einen müssen Sie Ergebnisberechnungen durchführen. Zum Beispiel, wenn Sie ein Blog, mit einer Reihe von Post s haben, können Sie entweder tun:

select count(*) from Post where BlogID = @BlogID 

die als

select PostCount from Blog where ID = @BlogID 

teurer und kann zum SELECT N+1 Problem führen, wenn Sie bin nicht vorsichtig.

Natürlich mit der zweiten Option müssen Sie mit der Datenintegrität zu halten, aber wenn die erste Option schmerzhaft genug ist, dann machen Sie es zum Funktionieren.

Achten Sie darauf, dass Sie nicht in die premature optimisation fallen. Tun Sie es in der normalisierten Weise, dann messen Sie Leistung gegen Anforderungen, und nur wenn es zu kurz ist, sollten Sie auf denormalise aussehen.

Answer 3

Es gibt eine sehr einfache Antwort auf Ihre Frage: Es kommt darauf an.

Zuerst würde ich Ihre Frage als "Was ist der Vorteil der Denormalisierung" umformulieren, denn Normalisierung ist das, was als Standard (als Ergebnis eines reinen logischen Modells) getan werden sollte und dann Denormalisierung kann für sehr spezifische Tabellen angewendet werden, bei denen die Leistung entscheidend ist. Das Hauptproblem der Denormalisierung besteht darin, dass das Management der Datenintegrität erschwert werden kann, die Vorteile jedoch in einigen Fällen die Risiken überwiegen.

Mein Rat für denormalization: tun Sie es nur, wenn es wirklich weh tut und stellen Sie sicher, dass Sie alle Szenarien abgedeckt, wenn es um die Integrität der Daten nach Inserts, Updates oder gelöscht.

Answer 4

ich habe die Normalisierung gefunden, in In einigen Fällen wird Leistung verbessern.

Kleine Tabellen lesen schneller. Eine schlecht denormalisierte Datenbank hat oft (a) längere Zeilen und (b) mehr Zeilen als ein normalisiertes Design.

Weniger kürzere Zeilen lesen bedeutet weniger physische E/A.

Answer 5

Um einige Punkte von früheren Plakaten zu unterstreichen: Ist das aktuelle Schema wirklich denormalisiert?Der richtige Weg (imho) eine Datenbank zu entwerfen ist:

• so gut verstehen, können Sie das System/Informationen
• Bauen Sie ein voll normalisierten Modell
• Dann modelliert werden, ob und wie Sie es für notwendig erachten, denormalize in einer gesteuert Art und Weise die Leistung zu verbessern

(es können auch andere Gründe denormalize, aber die einzigen, die ich von off-Hand denken kann politische diejenigen sind - haben den vorhandenen Code zu entsprechen, haben die Entwickler/Manager es nicht mögen, etc.)

Mein Punkt ist, wenn Sie nie vollständig normalisiert, Sie nicht über eine normalisierte Datenbank haben, haben Sie eine unnormalisierten bekam ein. Und ich denke, Sie können sich an beschreibendere, weniger höfliche Ausdrücke für diese Datenbanken erinnern.

Answer 6

Normalisierte Schemas tendieren dazu, bessere Ergebnisse für INSERT/UPDATE/DELETE zu erzielen, da keine "Aktualisierungsanomalien" vorliegen und die tatsächlichen Änderungen, die vorgenommen werden müssen, stärker lokalisiert sind.

SELECT-Werte sind gemischt. Die Denormalisierung materialisiert im Wesentlichen einen Join. Es besteht kein Zweifel, dass das Verwirklichen einer Verbindung manchmal hilft, jedoch ist die Materialisierung oft sehr pessimistisch (wahrscheinlich öfter als nicht), also gehen Sie nicht davon aus, dass Denormalisierung Ihnen helfen wird. Außerdem sind normalisierte Schemas im Allgemeinen kleiner und benötigen daher möglicherweise weniger E/A. Ein Join ist nicht unbedingt teuer, also nicht automatisch davon ausgehen, dass es sein wird.

Answer 7

"Normalisierung" gilt nur und ausschließlich zu logische Design einer Datenbank.

Das logische Design einer Datenbank und das physikalische Design einer Datenbank sind zwei völlig unterschiedliche Dinge. Die Datentheorie hat immer so gedacht, dass die Dinge so sind. Die Tatsache, dass die Entwickler, die diese Unterscheidung übersehen oder ignorieren (aus Unwissenheit oder aus Unachtsamkeit oder aus Faulheit oder aus irgendeinem anderen so genannten - aber ungültigen "Grund") die überwiegende Mehrheit sind, macht sie nicht richtig.

Ein logisches Design kann gesagt werden, um normalisiert zu werden oder nicht, aber ein logisches Design trägt nicht inhärent irgendein "Leistungsmerkmal" überhaupt. Genau wie 'c: = c + 1;' trägt inhärent kein Leistungsmerkmal.

Eine physikalische Design bestimmt "Leistungsmerkmale", aber dann wieder ein physisches Design hat einfach nicht die Qualität von "normalisiert oder nicht".

Diese fehlerhafte Wahrnehmung von "Normalisierung, die Leistung verletzt" ist wirklich nichts anderes als der konkrete Beweis, dass alle DBMS-Motoren, die heute existieren, nur an physikalischen Designoptionen ernsthaft mangeln.

Answer 8

Ich wollte auf Henrik Opel's #3 bullet point näher ausführen. Entwicklungskosten könnte gehen, aber sie müssen nicht. In der Tat sollte die Normalisierung einer Datenbank die Verwendung von Tools wie ORMs, Code Generators, Report Writern usw. vereinfachen oder ermöglichen. Diese Tools können den Zeitaufwand für die Datenzugriffsebene Ihrer Anwendungen erheblich reduzieren und die Entwicklung bis hin zum Hinzufügen von Geschäftsprozessen vorantreiben Wert.

Sie können eine gute StackOverflow-Diskussion here über den Entwicklungsaspekt von normalisierten Datenbanken finden. Es gab viele gute Antworten, Kommentare und Dinge zum Nachdenken.