Ich denke, dass die gesamte Idee von NoSQL-Datenspeichern und das Konzept von Dokumentendatenbanken derzeit so neu und anders als die etablierten Ideen sind, die relationale Speicherung vorantreiben, dass es derzeit (wenn überhaupt) nur sehr wenige Best Practices gibt.
Wir wissen an dieser Stelle, dass die Regeln für das Speichern Ihrer Daten in beispielsweise CouchDB (oder jeder anderen Dokumentendatenbank) ziemlich anders sind als für eine relationale Datenbank. Zum Beispiel ist es so ziemlich eine Tatsache, dass Normalisierung und das Anstreben von 3NF nichts ist, was man anstreben sollte. Eines der üblichen Beispiele wäre das eines einfachen Blogs.
In einem relationalen Store hätten Sie jeweils eine Tabelle für „Beiträge“, „Kommentare“ und „Autoren“. Jeder Autor hätte viele Posts und jeder Post hätte viele Kommentare. Dies ist ein Modell, das gut genug funktioniert und sich gut über jede relationale Datenbank abbilden lässt. Das Speichern derselben Daten in einer docDB wäre jedoch höchstwahrscheinlich etwas anders. Sie hätten wahrscheinlich so etwas wie eine Sammlung von Post-Dokumenten, in die jeweils ein eigener Autor und eine Sammlung von Kommentaren eingebettet sind. Natürlich ist dies wahrscheinlich nicht die einzige Möglichkeit, dies zu tun, und es ist ein gewisser Kompromiss (jetzt Abfragen für einen einzelnen Beitrag sind schnell - Sie führen nur einen Vorgang aus und erhalten alles zurück), aber Sie haben keine Möglichkeit, die Beziehung zwischen Autoren und Beiträgen aufrechtzuerhalten (da alles Teil des Beitragsdokuments wird).
Ich habe auch Beispiele gesehen, die ein "type"-Attribut verwenden (in einem CouchDB-Beispiel). Sicher, das klingt nach einem praktikablen Ansatz. Ist es das beste? Ich habe keine Ahnung. Sicherlich würden Sie in MongoDB separate Sammlungen innerhalb einer Datenbank verwenden, wodurch das Typattribut völliger Unsinn wird. In CouchDB aber... vielleicht ist das so Beste. Die anderen Alternativen? Separate Datenbanken für jeden Dokumententyp? Das scheint ein bisschen durchgeknallt zu sein, also würde ich mich selbst zur "Typ" -Lösung neigen. Aber das bin nur ich. Vielleicht gibt es etwas Besseres.
Mir ist klar, dass ich hier ziemlich viel geschwafelt und sehr wenig gesagt habe, höchstwahrscheinlich nichts, was Sie nicht schon wussten. Was ich aber sagen möchte:Ich denke, es liegt an uns, mit den Tools, die wir haben, und den Daten, mit denen wir arbeiten, zu experimentieren, und im Laufe der Zeit werden sich die guten Ideen verbreiten und werden die Best-Practices. Ich denke nur, du fragst etwas zu früh im Spiel.
