Normalisieren oder Denormalisieren zum Speichern von Revisionsverläufen in einem RDBMS?

Question

Ich habe eine grundlegende CRUD Web App, wo Menschen Artikel erstellen/bearbeiten können. Ich möchte jetzt die Möglichkeit hinzufügen, Revisionshistorien aller Bearbeitungen zu behalten. Derzeit hat ich einen Artikel Tabelle, die wie folgt aussieht:

Article(id, title, content, author_id, category_id, format) 

I 2 Optionen in Betracht gezogen habe mein aktuelles Schema zum Ändern Unterstützung für Revisionsgeschichte hinzuzufügen. Grundidee ist, dass jede einzelne Bearbeitung für einen Artikel als Datensatz in einer Revisionstabelle gespeichert wird. Also Artikel und Revisionen ist eine Eins-zu-viele-Beziehung.

Erste Option (normalisiert): Eine Tabelle für Artikelmetadaten, eine für Revisionen. Keine doppelten Daten gespeichert.

Article(id, title, category_id) 
Revision(id, content, author_id, format) 

2. Option (de-normalisiert): Zwei Tabellen wie Option 1, aber mit einigen doppelten Spalten.

Article(id, title, content, author_id, category_id, format) 
Revision(id, article_id, content, author_id, format) 

Ich denke, mit der zweiten Option zu gehen, weil es meine Codierung viel einfacher (weniger komplex, weniger Codezeilen) machen. Ich weiß, dass es nicht "akademisch" und "rein" ist, aber mein persönliches Gefühl ist, dass das Hinzufügen von zusätzlichen Joins die Code-Pflege beeinträchtigen würde. Außerdem sollte die Performance besser sein, da nicht so viele Joins durchgeführt werden müssen.

Ist dies ein guter Weg, um diese Aufgabe zu bewältigen? Möglicherweise irgendwelche unvorhergesehenen oder langfristigen Folgen, die ich übersehen habe?

Answer 1

Das Leistungsargument ist Unsinn - Sie tun weniger JOIN s, aber RDBMS sind für JOIN s optimiert.

Allerdings ziehen Sie möglicherweise ein Los mehr Daten vom Server als notwendig ist, die nicht weg optimiert werden können.

Sie haben möglicherweise auch eine Konsistenz Problem. Das Duplizieren von Daten für denselben Artikel in verschiedenen Tabellen führt zu Inkonsistenzen. Was ist, wenn die Revisionsdatensätze und der Artikelsatz unterschiedliche Werte für format oder author haben? Woher weißt du, was richtig ist? Was passiert, wenn die content in Articles keiner der Revisionen entspricht?

Sie sollten dies wirklich normalisieren. Ich würde ein CurrentRevision Feld zu Ihrer Articles Tabelle hinzufügen, um mit der gegenwärtigen Version zu verbinden, und Sie sollten eine ArticleID in der Revisions Tabelle haben, um die zwei zusammen zu verbinden.

Answer 2

Wenn Sie sich für Ihre Daten interessieren, werden Sie im "denormalisierten" Fall nicht weniger Code haben - Sie müssen erzwingen, dass die letzte Zeile in Revision immer mit der Kopie in Article übereinstimmt. Dies ist in der parallelen Umgebung alles andere als trivial - Sie müssen Ihre Sperre sehr sorgfältig durchführen!

(Wenn Sie Revision und Article nicht die gleiche Kopie enthalten, dann ist dies noch schlimmer - Sie werden auf DBMS angewiesen für die Durchsetzung des Revision Primärschlüssel nicht in der Lage sein!)

Mit einem DBMS mächtig genug, Sie könnten Ihren Kuchen haben und ihn auch essen - zum Beispiel können Oracle materialisierte Ansichten die Daten für Sie "vor-verbinden", ohne das tatsächliche Datenmodell denormalisieren zu müssen.

Auch wenn Sie nicht über ein solches DBMS verfügen, ziehen Sie eine Denormalisierung in Erwägung, nachdem Sie die Leistung auf realistische Datenmengen gemessen haben. Ja, JOINS kann teuer sein, aber sind sie auch teuer in Ihrer besonderen Situation? Nur Messungen können es zeigen. Verwendung Identifizierung Beziehung/natürlichen Schlüssel wie folgt

---

BTW, betrachten:

Die revision_no wächst monoton wie Sie Revisionen unter dem angegebenen Artikel hinzufügen.

Die B-Tree-Struktur unter dem Revision PK macht es sehr effizient, die neueste (oder irgendeine!) Revision des gegebenen Artikels zu finden. Sofern Sie keine alternativen Schlüssel in Ihrer Frage haben, könnten Sie auch cluster die Revision und (unter Oracle) sogar die Vorderkante des Clustering-Index zu komprimieren, so Raum Overhead von wiederholen article_id wird annulliert.