Wenn Sie für den Ordner keine Metadaten benötigen, außer dem Namen, mit dem Sie auch fortfahren könnten:

• Sammlungen: User , Task
• Task hat Feld folder
• User hat die Arrays read_access und write_access

Dann

• Sie können eine Liste aller Ordner mit

  abrufen

  db.task.distinct ("Ordner")

• Der Ordner, auf den ein bestimmter Benutzer zugreifen kann, wird automatisch beim Abrufen des Benutzerdokuments abgerufen, sodass diese beim Anmelden grundsätzlich bekannt sind.

• Sie können alle Aufgaben abrufen, die ein Benutzer mit

  lesen kann

  db.task.find ({Ordner: {$ in: read_access}})

  mit read_access als das entsprechende Array, das Sie aus Ihrem Benutzerdokument erhalten haben. Dasselbe mit write_access .

• Sie können alle Aufgaben in einem Ordner mit einer einfachen Suchabfrage für den Ordnernamen finden.

• Das Umbenennen eines Ordners kann mit einer Aktualisierungsabfrage für jede Sammlung erreicht werden.

• Das Erstellen eines Ordners oder das Verschieben einer Aufgabe in einen anderen Ordner kann ebenfalls auf einfache Weise erreicht werden.

Also ohne Metadaten für Ordner würde ich das machen. Wenn Sie Metadaten für Ordner benötigen, kann es etwas komplizierter werden, aber im Grunde können Sie diese unabhängig von den Aufgaben und Benutzern verwalten, indem Sie eine Ordnersammlung mit den Metadaten mit _id als Ordnernamen in user und task verwenden. .

Bearbeiten:

Vergleich der verschiedenen Ansätze

Gestolpert über diesen Link , der für Sie von Interesse sein könnte . Es gibt eine Diskussion über den Übergang von einem relationalen Datenbankmodell zu Mongo. Der Unterschied liegt darin, dass man in einer relationalen Datenbank normalerweise versucht, das dritte Normalformular zu verwenden, wobei eines der Ziele darin besteht, Verzerrungen zu vermeiden Zu jeder Form von Zugriffsmustern können Sie in mongodb versuchen, Ihre Daten so zu modellieren, dass sie am besten zu Ihren Zugriffsmustern passen (ohne dabei mögliche Datenanomalien durch Redundanz einzuführen).

Also vor diesem Hintergrund:

• Ihr Modell A ist ein Weg, wie Sie es in einer relationalen Datenbank tun können (jeder Informationstyp in einer Tabelle, die über die ID referenziert wird)
• model B wäre auf ein Zugriffsmuster zugeschnitten, bei dem Sie immer einen vollständigen Ordner auflisten und Aufgaben nur beim Öffnen des Ordners bearbeitet werden (wenn Sie einen Ordner abrufen, haben Sie alle Aufgaben ohne einen zusätzlichen Abfrage)
• C wäre ein anderes relationales Modell als A und ich denke etwas näher an die dritte Normalform (ohne die genauen Tabellen zu kennen)
• Mein Vorschlag würde den Ordnerzugriff nicht so optimal unterstützen wie B , aber es würde es einfacher machen, einzelne Aufgaben anzuzeigen und zu bearbeiten

Probleme, die bei den Schemas auftreten können: Da A und C grundsätzlich relational sind, können Sie ein Problem mit Fremdschlüsseln bekommen, da mongodb keine Fremdschlüsselzwänge durchsetzt ( ZB könnten Sie einen Ordner löschen, während noch Aufgaben auf C verweisen, oder eine Aufgabe, ohne ihre Referenz im Ordner A zu löschen. Sie können dieses Problem umgehen, indem Sie es aus der Anwendung erzwingen. Für B kann das 16 MB-Dokumentlimit zu einem Problem werden, das dadurch vermieden werden kann, dass Ordner in mehrere Dokumente aufgeteilt werden, wenn sie eine bestimmte Aufgabenanzahl erreichen.

Also neue Schlussfolgerung: Ich denke, dass A und C Ihnen möglicherweise nicht die Vorteile von mongodb (und vielleicht sogar mehr Arbeit in mongodb als in sql) zeigen Sie sind das, was Sie in einer traditionellen relationalen Datenbank tun würden, für die mongodb nicht vorgesehen ist (zB die fehlende Join-Anweisung, keine Fremdschlüsselbeschränkungen). Zusammengefasst entspricht B am ehesten Ihrem Zugriff. "Normalerweise (vor allem für die Synchronisierung) werden Aufgaben nach Ordner angefordert, während Sie nach dem Öffnen des Ordners die Aufgaben einfach bearbeiten und verschieben können.