Sie müssen darüber nachdenken, wie Sie die Anwendung dokumentenorientiert angehen. Wenn Sie einfach versuchen zu replizieren, wie Sie das Problem in einem RDBMS modellieren würden, schlagen Sie fehl. Es gibt auch verschiedene Kompromisse, die Sie möglicherweise eingehen möchten. ([ed: Ich bin mir nicht sicher, wie dies mit dem Argument zusammenhängt, aber:] Denken Sie daran, dass das Design von CouchDB davon ausgeht, dass Sie einen aktiven Cluster mit vielen Knoten haben, die jederzeit ausfallen können. Wie wird Ihre App mit einem der Datenbankknoten umgehen, aus denen sie verschwindet? darunter?)
Eine Möglichkeit, darüber nachzudenken, besteht darin, sich vorzustellen, Sie hätten keine Computer, nur Papierdokumente. Wie würden Sie einen effizienten Geschäftsprozess erstellen, indem Sie Papierstücke herumreichen? Wie können Sie Engpässe vermeiden? Was ist, wenn etwas schief geht?
Ein weiterer Aspekt, über den Sie nachdenken sollten, ist die eventuelle Konsistenz, bei der Sie schließlich in einen konsistenten Zustand geraten, aber möglicherweise für einen bestimmten Zeitraum inkonsistent sind. Dies ist ein Gräuel im RDBMS-Land, aber in der realen Welt äußerst verbreitet. Das kanonische Transaktionsbeispiel ist die Überweisung von Geld von Bankkonten. Wie geschieht dies tatsächlich in der realen Welt - durch einzelne Atomtransaktionen oder durch verschiedene Banken, die sich gegenseitig Kredit- und Lastschriften ausstellen? Was passiert, wenn Sie einen Scheck ausstellen?
Schauen wir uns also Ihre Beispiele an:
- CRUD von Entitäten mit einigen Feldern mit einem eindeutigen Index.
Wenn ich dies in CouchDB-Begriffen richtig verstehe, möchten Sie eine Sammlung von Dokumenten haben, bei denen garantiert ist, dass ein benannter Wert in all diesen Dokumenten eindeutig ist? Dieser Fall kann im Allgemeinen nicht unterstützt werden, da Dokumente möglicherweise auf verschiedenen Replikaten erstellt werden.
Wir müssen uns also das Problem der realen Welt ansehen und sehen, ob wir das modellieren können. Brauchen Sie sie wirklich, um einzigartig zu sein? Kann Ihre Anwendung mehrere Dokumente mit demselben Wert verarbeiten? Müssen Sie eine eindeutige Kennung zuweisen? Können Sie das deterministisch tun? Ein häufiges Szenario, in dem dies erforderlich ist, besteht darin, dass Sie eine eindeutige sequentielle Kennung benötigen. Dies ist in einer replizierten Umgebung schwer zu lösen. In der Tat ist es unmöglich, wenn die eindeutige ID in Bezug auf die erstellte Zeit streng sequentiell sein muss, wenn Sie die ID sofort benötigen. Sie müssen mindestens eine dieser Einschränkungen lockern.
- E-Commerce-Web-App wie ebay
Ich bin mir nicht sicher, was ich hier hinzufügen soll, da der letzte Kommentar, den Sie zu diesem Beitrag abgegeben haben, "sehr nützlich! Danke" war. Fehlt in dem dort beschriebenen Ansatz etwas, das Ihnen immer noch ein Problem bereitet? Ich fand die Antwort von MrKurt ziemlich vollständig und fügte eine kleine Verbesserung hinzu, die den Streit reduzieren würde.