Ein Vorgehen, wenn Du ein Programm schreibst, ist immer, dass Du Dir im Detail überlegst, was es machen soll. Das wird dann bei einigen Vorgehen oft als User Stories beschrieben. Wenn Du sowas umsetzen willst, dann kommt es dazu, dass Du Elemente identifizierst, die implementiert werden müssen.
Hier hast Du dann also Karteikarten, die in Ordnern oder Karteikästen organisiert sind. Das kannst Du also entsprechend modellieren.
Und wenn Du dann die User-Stories betrachtest, dann weisst Du, was mit den Daten alles passieren muss. Da kannst Du also hin gehen und überlegen, was für Zugriffe notwendig sind und was daher notwendig ist. Eine Möglichkeit ist, dass Du die Ordner in einer Collection speicherst ohne die Karten. Die Karten haben dann die id des Ordners, in dem sie sind.
Wenn Du aber immer einen ganzen Ordner brauchst, dann könntest Du einfach die Ordner zusammen mit den Karteikarten speichern. Das geht auch. Das macht das Laden eines Ordners einfach. Aber wenn Du Anpassungen hast, dann wird das problematisch. Sprich: Eine Karte wird von einem Ordner in einen anderen verschoben: Du lädst also beide Ordner (mit evtl. jeweils tausenden von Karten) um die Änderung zu machen und dann beide wieder zu speichern. Klingt nicht wirklich gut. So also solche Verschiebe-Operationen geplant sind, dann solltest Du das trennen.
Das ist nur ein Beispiel. Aber ich hoffe, es zeigt, was ich meine.
Daher sind so pauschal keine Aussagen machbar. Aber so eine Aufteilung, dass die Karteikarten in einer eigenen Collection sind und nur eine ID von einem Ordner haben, hört sich erst einmal vernünftig an und dürfte nicht mit wirklichen Problemen kommen.
Aber die Fragestellung ist erst einmal: Brauchst Du das wirklich? Wenn der Ordner nur aus einem Begriff besteht wie "Englisch", dann brauchst du da ggf. gar keine eigene Entity. Das ist dann einfach nur ein String Attribut in der Karteikarte.
Ein Nachteil dabei: Wenn Du einen Ordner umbenennen willst, dann musst Du alle Karteikarten des Ordners anpacken.
