Was sind die Vor- / Nachteile der Entnormalisierung einer Unternehmensanwendungsdatenbank, weil dadurch das Schreiben von Berichten vereinfacht wird?
Pro - das Entwerfen von Berichten in SSRS wird wahrscheinlich "einfacher" sein, da keine Joins erforderlich sind.
Con - Die Entwicklung / Pflege der App für den Umgang mit de-normalisierten Daten wird durch die Duplizierung von Daten und die Synchronisierung schwieriger.
Andere?
Denormalisierung für Berichte ist schlecht, m'kay.
Erstellen von Ansichten oder ein denormalisiertes Data Warehouse ist gut.
Die Ansichten haben die meisten meiner Berichtspflichten gelöst. Data Warehouses sind großartig, wenn Benutzer fast ständig Berichte generieren oder wenn Ihre Ansichten langsamer werden.
Deshalb möchten Sie Ihre Datenbank normalisieren
- Freigeben der Sammlung von Beziehungen aus unerwünschten Einfügungs-, Aktualisierungs- und Löschungsabhängigkeiten;
- Um die Notwendigkeit der Umstrukturierung der Sammlung von Beziehungen als neue Arten von Daten zu reduzieren, und damit die Lebensdauer von Anwendungsprogrammen zu erhöhen;
- Um das relationale Modell informativer für die Benutzer zu machen;
- Um die Sammlung von Relationen neutral gegenüber den Abfragestatistiken zu machen, wo sich diese Statistiken mit der Zeit ändern können.
-E.F. Codd, "Weitere Normalisierung des relationalen Datenbank-Modells" über wikipedia
Das einzige Mal, dass Sie eine De-Normalisierung in Betracht ziehen sollten, ist, wenn die Zeit, die der Bericht benötigt, nicht akzeptabel ist. Die De-Normalisierung führt zu Konsistenzproblemen, die manchmal insbesondere in großen Datensätzen nicht festgestellt werden können.
Denormalisieren Sie nicht nur, um die Komplexität in der Berichterstellung zu beseitigen, dies kann im Rest der Anwendung zu großen Problemen führen. Entweder erzwingen Sie nicht die Regeln, die zu schlechten Daten führen, oder wenn Sie das tun, dann können Einfügungen, Löschungen und Aktualisierungen für alle, nicht nur für die zwei oder drei Personen, die Berichte ausführen, ernsthaft verlangsamt werden.
Wenn die Berichte wirklich nicht ordnungsgemäß ausgeführt werden können, erstellen Sie ein denormalisiertes Data Warehouse, und füllen Sie es in einem nächtlichen oder wöchentlichen Feed auf. Die Art von Berichten, die dies normalerweise benötigt, ist im Allgemeinen nicht relevant, wenn die Daten aktuell sind, da es sich normalerweise um monatliche, vierteljährliche oder jährliche Berichte handelt, die nach der Tat große Datenmengen verarbeiten (und insbesondere aggregieren). p>
Sie können beides tun ... lassen Sie die normalisierte Datenbank für Anwendungen. Erstellen Sie dann eine denormalisierte Datenbank für Berichte und erstellen Sie eine Anwendung, die regelmäßig Daten von einer Datenbank in die andere kopiert.
Schließlich müssen Berichte nicht immer die neuesten aktualisierten Daten enthalten. In den meisten Fällen können Sie problemlos alle 1 Stunde ein Update in der Berichtsdatenbank und nur einmal am Tag durchführen.
Über die Data Warehouse- und View-Lösungen in anderen Antworten hinaus, die in mancher Hinsicht gut sind, wenn Sie bereit sind, etwas Leistung zu opfern, um ein gutes Ergebnis für die letzte Sekunde zu erhalten, aber trotzdem eine normalisierte Datenbank haben möchten Auf Oracle eine Materialized View mit schneller Aktualisierung bei Commit oder in Sql Server, könnten Sie Clustered-Indizes für eine Ansicht verwenden.
Ein weiterer Nachteil ist, dass die Daten wahrscheinlich nicht in Echtzeit vorliegen, da es einige Zeit gibt, um die Daten zu bewegen, um von einer normalisierten Form zu einer de-normalisierten zu gelangen. Wenn jemand möchte, dass der Bericht bis zur Sekunde erscheint, in der er angefordert wurde, kann das in dieser Situation schwierig sein.
Wenn dies eine Duplizierung der Synchronisation im ursprünglichen Post ist, tut mir leid, dass ich das nicht so gesehen habe.
Tags und Links report relational-database normalization