Dokumentorientierte Datenbank - Was passiert, wenn sich die Dokumentdefinitionen ändern?

Question

Nach meinem Verständnis können Sie beliebige nicht strukturierte Informationen in eine dokumentorientierte Datenbank eingeben. Lassen Sie uns ein Dokument wie folgt vorstellen:

{ 
    name: 'John Blank', 
    yearOfBirth: 1960 
} 

Später, in einer neuen Version, diese Struktur zu

{ 
    firstname: 'John', 
    lastname: 'Blank', 
    yearOfBirth: 1960 
} 

Refactoring ist Wie tun Sie dies mit dokumentenorientierte Datenbanken? Müssen Sie Merge-Skripte erstellen, die alle Ihre Einträge in der Datenbank verändern? Oder gibt es bessere Möglichkeiten, mit Veränderungen in der Struktur umzugehen?

Answer 1

Refactoring hier bedeutet, dass es eine deterministische Zuordnung vom alten Schema zum neuen Schema gibt. Die effektivste Option besteht also darin, dasselbe mit einer SQL-Datenbank zu tun und die Dokumente tatsächlich zu aktualisieren.

Document-Oriented Databases gibt Ihnen eine andere Option, obwohl es davon abhängt, welches DODB und wie Sie es auf dem Front-End verwenden. Diese Option besteht darin, die Daten einfach zu belassen und die "alte" Definition in Ihrer Anwendung als eine Art Rückwärtskompatibilität zu unterstützen. Mit anderen Worten, Sie machen diese Übersetzungen im Gegensatz zu einem permanenten einmaligen Update on-the-fly.

Dies ist nicht wirklich eine Option mit einer SQL-Datenbank, weil Sie die veraltete Spalte herum und möglicherweise indiziert halten müssen. Mit einem DODB verschwenden Sie nicht wirklich Daten oder Indexraum. Sie müssten die Vorteile gegen die Nachteile abwägen.

Der Hauptnachteil ist offensichtlich die Inkonsistenz, die mit der Zeit zunehmen und zu Fehlern führen kann. Ein weiterer Nachteil ist möglicherweise der rechnerische Aufwand, dies on-the-fly zu tun, oder die Unfähigkeit, die neue Struktur effektiv zu nutzen (zum Beispiel könnten Sie nur die lastname indizieren). Also, meistens denke ich, ich würde einfach ein Massenupdate machen.

Es gibt jedoch einen klaren Vorteil, die alten Dokumente zu bewahren; Wenn Sie nicht sicher sind, ob Ihr Refactoring perfekt ist - wenn zum Beispiel die Daten in Ihrer name-Spalte keiner konsistenten Konvention entsprachen, ist es in einigen Fällen lastname, firstname und in anderen Fällen firstname lastname und in anderen Fällen ist es company name - dann Wenn Sie Ihre Conversions ohne permanente Aktualisierung durchführen, können Sie das Mapping im Laufe der Zeit verfeinern, sodass Sie die Felder firstname und lastname verwenden können, wenn sie verfügbar sind, aber auf das name Ratespiel für Legacy-Daten zurückgreifen.

Wie gesagt, würde ich wahrscheinlich die zweite Option für Ausnahmefälle reservieren, wo ich nicht zuversichtlich bin, dass ich das "Refactoring" für jeden Datensatz/Dokument korrigieren kann. Nichtsdestoweniger ist es eine Option, die Ihnen zur Verfügung steht, die Sie nicht wirklich mit anderen Arten von Datenbanken haben.

Abgesehen von diesen beiden sehe ich keine anderen klaren Alternativen. Es ist eine Art binäre Entscheidung; entweder aktualisieren Sie die vorhandenen Daten permanent oder nicht.