Wie kann ich überzeugend gegen das Duplizieren von Datenbankspalten argumentieren?

47

Ich habe angefangen, in einer neuen Organisation zu arbeiten, und eines der Muster in der Datenbank ist das Duplizieren von Feldern, um den Geschäftsanalysten das Schreiben von Abfragen zu erleichtern. Wir verwenden Django und sein ORM.

In einem Fall behalten wir ein MedicalRecordNumber- Objekt mit einer eindeutigen Zeichenfolge bei, die einen Patienten in einem bestimmten Kontext identifiziert. Wir haben Registrierungsobjekte , die Patienten verfolgen und MedicalRecordNumbers zugeordnet haben , aber anstatt eine Fremdschlüsselbeziehung zu verwenden, duplizieren sie die Zeichenfolge, um das Schreiben eines Joins zu vermeiden ( nicht aus Leistungsgründen). Dieses Muster ist in der gesamten Datenbank verbreitet.

Für mich ist es wichtig, dass ein Datenmodell sauber ist, damit ich gut darüber nachdenken kann. Unnötige Komplexität ist eine Verschwendung meiner begrenzten kognitiven Verarbeitungszeit. Es ist ein systematisches Problem. Es ist ein Problem, dass es nicht leicht ist, Beitritte zu schreiben. Ich möchte nicht unbedingt dafür eintreten, dass wir zurückgehen und das Schema ändern, aber ich würde gerne in der Lage sein, die Probleme mit dieser Art der Vervielfältigung überzeugend zu artikulieren.

database-design

— canisrufus
quelle

2

Was bedeutet es, "sich beim Schreiben nicht wohl zu fühlen"? Wie erklären sie das?

— Skriptin

9

Arbeiten diese Leute für Sie? Bist du ihr Vorgesetzter? Die meisten Ihrer Begründungen finden Sie hier: en.wikipedia.org/wiki/Database_normalization . Ja, sie müssen die Verwendung von Joins verbessern.

— Robert Harvey

1

Haben Sie in der Literatur nachgeschlagen, warum eine Normalisierung wünschenswert ist?

— Nathan Tuggy

17

Würde das Hinzufügen von Ansichten, mit denen der Join intern ausgeführt wird, das Schreiben von Abfragen nicht genauso einfach machen? Sie könnten sie als Alternative vorschlagen.

— CodesInChaos

1

Haben Sie dies (höflich) mit Gleichaltrigen und Senioren kommuniziert? Was sind ihre Rechtfertigungen, welche Überlegungen machen sie? Es gibt viele mögliche Gründe, warum dies eine gute Idee sein könnte (auch wenn Sie sagen, "Leistung ist nicht der Grund", welche Beweise müssen Sie dafür liefern?). Haben Sie, bevor Sie sie beschuldigen, zu faul und / oder starr zu sein, über die Gründe nachgedacht (und gefragt), warum sie das Design so haben, wie es ist? Vielleicht gibt es weit mehr Lese- als Schreibvorgänge (analytics heavy DB)? Nachverfolgung ändern? Historische Daten? Fragen Sie alle - vielleicht kennt jemand den wahren Grund.

— Luaan

128

Ihre operative Datenbank sollte stark normalisiert sein, um Anomalien zu reduzieren .

Ihre Analysedatenbank (Warehouse) sollte stark denormalisiert sein, um die Analyse zu vereinfachen.

Wenn Sie keine separate Analysedatenbank haben, sollten Sie einige stark denormalisierte [materialisierte] Ansichten erstellen.

Wenn Sie Ihren leitenden Geschäftsanalysten / Managern anweisen, viele Verknüpfungen für eine einfache Analyse durchzuführen, können Sie entlassen werden.

Agile Data Warehouse Design ist ein gutes Buch

Siehe meine schnellen n‘schmutzigen Data - Warehouse - Tipps hier

— Neil McGuigan
quelle

9

Das ist der richtige Weg.

— Nit

6

+1 Genau dafür sind Ansichten gedacht: Ermöglichen einer denormalisierten Ansicht in einer normalisierten Datenbank.

— Nzall,

4

Absolut richtig, aber ich denke, "Anomalien reduzieren" sollte mehr betont werden, da dies die primäre Antwort auf die Frage ist. Die häufigsten (nur?) Anomalie Sie mit Datenduplizierung sehen werden / Denormalisierung ist , dass die Spalten irgendwie mit widersprüchlichen Daten zur gleichen Zeit bevölkert bekommen, Sie ohne die Möglichkeit des Ausscheiden zu wissen , was die realen Daten sollte sein und keine Art und Weise zu bestimmen, was schief gelaufen ist. Letzteres kann durch die massive Nachverfolgung von Änderungen gemildert werden, aber dies ist nicht billig oder nicht schnell, um das Problem zu finden. Kostengünstiger, um das Problem vollständig zu vermeiden.

— jpmc26

2

Ein weiterer zu berücksichtigender Aspekt ist, dass selbst wenn die Entwickler in der Lage sind, die Daten korrekt zu halten (zweifelhaft), dies eine enorme Belastung ihrer Ressourcen darstellt, um sicherzustellen, dass jedes doppelte Feld aktualisiert wird, wenn dies zur Aufrechterhaltung der Konsistenz erforderlich ist.

— Nate CK

1

@Panzercrisis Eine Transaktion ist nur dann "implizit", wenn am Ende Ihrer Abfrage ein automatisches Commit ausgeführt wird. Dies sollte bei einer Produktionsdatenbank normalerweise nicht der Fall sein. In einer Anwendung sollten Transaktionen automatisch initiiert und ein Commit getrennt von der Abfrage ausgegeben werden. Dies ist eine kleine Vorabinvestition in die Anwendung, vereinfacht jedoch Codeänderungen, die das Hinzufügen von Datenbankaufrufen erfordern, und verringert die Bedenkzeit eines Entwicklers (verbessert die Entwicklungsgeschwindigkeit, verringert Entwicklungsfehler). Diese Art von Design passt auch gut zu Dingen wie Verbindungspooling.

— jpmc26

57

Ich verstehe, warum jemand vermeiden möchte, einen Join für jede Auswahl zu schreiben .

Sie können jedoch einmalig eine Ansicht mit dem Join erstellen und diese anstelle Ihrer nicht normalisierten Tabelle verwenden.

So kombinieren Sie den Vorteil der Normalisierung mit dem Komfort einer einfachen Auswahl.

— knut
quelle

12

Views sind deine Freunde. Verwenden Sie sie großzügig. Und für die Leistung können Sie sogar Materialized Views verwenden, wenn Ihr RDBMS diese unterstützt.

— VH-NZZ

13

Die bereits überarbeiteten Antworten befassen sich hauptsächlich mit dem "Vermeiden von Doppelarbeit" (mithilfe von Ansichten), nicht aber mit dem Warum. Sie zeigen im Grunde, dass das Duplizieren von Spalten die falsche Lösung für das Problem ist, das Schreiben von Abfragen zu vereinfachen. Aber die Frage "Warum keine zufällige Spalte nur zum Teufel duplizieren?" noch steht.

Die Antwort lautet "Wegen Murphys Gesetz". Murphys Gesetz besagt, dass:

Wenn etwas schief gehen kann, wird es.

In diesem Fall wird angenommen, dass der Inhalt jedes Zeilenfelds einer duplizierten Spalte mit dem Inhalt jedes entsprechenden Zeilenfelds der ursprünglichen Spalte identisch ist. Was schief gehen kann, ist, dass der Inhalt einiger Zeilenfelder von den Originalen abweichen kann und Chaos anrichtet. Sie könnten denken, dass Sie alle erdenklichen Vorkehrungen getroffen haben, um sicherzustellen, dass sie sich nicht unterscheiden, aber Murphys Gesetz besagt, dass sie sich unterscheiden, da sie sich unterscheiden können. Und es wird Chaos geben .

Betrachten Sie als Beispiel, wie dies geschehen kann, einfach die Tatsache, dass die duplizierten Spalten nicht durch Magie gefüllt werden. Jemand muss tatsächlich Code schreiben, in dem Werte gespeichert werden, wenn Zeilen in der Originaltabelle erstellt werden, und Jemand muss Code schreiben, der sie immer dann aktualisiert, wenn die Originale geändert werden. Abgesehen von der Tatsache, dass dies zu einer übermäßigen Belastung des Codes führt, der Daten in die Datenbank eingibt (und der per Definition weitaus wichtiger ist als jeder Code, der einfach die Datenbank abfragt), könnte jemand irgendwo unter bestimmten Umständen vergessen diese Vervielfältigung durchzuführen. Dann unterscheiden sich die Werte. Sie können sich auch daran erinnern, die Vervielfältigung auszuführen, jedoch nicht innerhalb einer Transaktion, sodass sie unter bestimmten seltenen Fehlerbedingungen möglicherweise weggelassen wird. Aber ich musste nicht wirklich meine Zeit damit verschwenden, diese Beispiele zu schreiben.Wenn es schief gehen kann, wird es.

— Mike Nakis
quelle

12

Es wird produktiver sein, wenn man es eher in Kompromissen als in Gut / Schlecht sieht. Sie tauschen die Vorteile der Normalisierung (insbesondere die Konsistenz) gegen die Vorteile der Benutzerfreundlichkeit von Abfragen aus.

Im Extremfall würde die Datenbank unbrauchbar, wenn die Daten stark inkonsistent würden. Auf der anderen Seite wäre die Datenbank nutzlos, wenn es für die Leute, die sie jeden Tag abfragen müssen, zu schwierig wäre, Ergebnisse zu erhalten, auf die sie zählen können.

Was können Sie tun, um Risiken und Kosten zu reduzieren?

Erstellen Sie ein Tool zur Konsistenzprüfung und führen Sie es regelmäßig aus.
Leiten Sie den Schreibzugriff über eine Software weiter, die die replizierten Daten konsistent aktualisiert.
Fügen Sie Ansichten hinzu oder erstellen Sie Abfragetools, die die Verknüpfungen automatisch ausführen, damit die Geschäftsleute die Informationen und nicht die DB-Interna berücksichtigen können.

— Jerry101
quelle

6

Ich denke, das stärkste Argument für die Normalisierung von Daten für Geschäftsanalysten ist, dass es die Datenintegrität fördert. Wenn Ihre Schlüsseldaten nur an einer Stelle (eine Spalte, eine Tabelle) gespeichert sind, ist es viel unwahrscheinlicher, dass die Daten durch falsche Aktualisierungen beschädigt werden. Ich denke, sie würden sich wahrscheinlich für die Wichtigkeit der Datenintegrität interessieren, daher könnte dies eine gute Möglichkeit sein, sie davon zu überzeugen, ihre Interaktionsweisen mit der Datenbank zu aktualisieren.

Eine etwas schwierigere Abfragemethode ist wahrscheinlich einer möglichen Datenbeschädigung vorzuziehen.

— Oleksi
quelle

6

Seine Leute werden argumentieren, dass sie gut genug sind, um sicherzustellen, dass alle Daten ordnungsgemäß aktualisiert werden (eine Voraussetzung, die ich bestreite, wenn sie sich mit Verknüpfungen unwohl fühlen). Vielleicht ist ein besseres Argument, dass Sie die meisten Vorteile von ACID, die RDBMS bietet, verlieren, wenn Sie auf Normalisierung verzichten.

— Robert Harvey

4

Wahrscheinlich, aber es ist alles eine Frage des Risikos. Sind sie bereit, das Risiko einer Beschädigung der Datenbank in Kauf zu nehmen, da dies das Abfragen erleichtert?

— Oleksi

1

Als Anwalt des Teufels wäre es ein offensichtliches Gegenargument, dass, wenn jemand ein Update vermasselt und Daten beschädigt, dies ein Problem mit oder ohne Normalisierung ist - und zumindest eine gewisse Redundanz in der Datenbank dies wahrscheinlicher macht dass jemand die Beschädigung bemerkt und sie möglicherweise sogar später beheben kann. (Natürlich ist die Ad-hoc- Denormalisierung kaum das zuverlässigste Fehlererkennungsschema, aber das Prinzip der Fehlerprüfung über Redundanz ist solide: So funktioniert die doppelte Buchführung .)

— Ilmari Karonen,

Oder anders ausgedrückt: Datenintegrität umfasst mehr als nur relationale Integrität. Mit einer vollständig normalisierten Datenbank können Sie die perfekte relationale Integrität auch dann aufrechterhalten, wenn jemand ein Update durcheinanderbringt. Dadurch werden die falsch aktualisierten Daten jedoch nicht weniger gestört.

— Ilmari Karonen

0

Hinzufügen zu dem, was die anderen Jungs oben vorgeschlagen haben. Dies ist eine Frage der Datenverwaltung. Sie müssen mit relevanten Stakeholdern zusammenarbeiten: Datenarchitekten und Datenverwaltern, um Datenprinzipien, Richtlinien und Namenskonventionen zu entwickeln.

Sei geduldig und arbeite methodisch. Veränderung wird nicht über Nacht geschehen.

— hlosukwakha
quelle

0

Verlassen.

Ehrlich gesagt, können Sie Monate damit verbringen, über Normalisierung, Konsistenz und die Bekämpfung verrückter Fehler zu streiten, die durch reine Faulheit verursacht werden, und dann aufhören.

Oder Sie können einfach Zeit und Frust sparen und jetzt aufhören.

Gute Programmierer sind sehr faule Leute. Sie verstehen Kunden- und Managementbedürfnisse. Aber am wichtigsten ist, dass sie verstehen, dass das Lösen von Problemen mit gut konzipierten und implementierten Lösungen ihnen persönlich RIESIGE Arbeit, Mühe und vor allem Qual und Stress erspart .

Sie arbeiten also viel besser an einem Ort, der gutes Engineering versteht und schätzt.

Viel Glück.

Nachgedacht: Vielleicht brauchen sie BI / OLAP-Tools ... http://en.wikipedia.org/wiki/Online_analytical_processing

— AK_
quelle