Ich habe viel mit relationalen Datenbanken und ein bisschen mit NoSQL-Datenbanken gemacht (nur damit Sie wissen, woher ich komme). IMHO sind NoSQL-Datenbanken am besten für Szenarien geeignet, in denen entweder eines oder mehrere zutreffen:
- Die Daten sind im Wesentlichen flach (nicht viele Beziehungen, fast wie eine alte Flat-Datei)
- Es gibt einen eindeutigen „Eltern“-Typ-Datensatz mit „Kind“-Datensätzen, die klein genug sind/auf die mit dem Elternteil häufig genug zugegriffen wird, um ihre direkte Einbettung in den Datensatz zu rechtfertigen.
- Sie brauchen die Freiheit, Felder im Rahmen des Zumutbaren hinzuzufügen/auszufüllen. Ich stelle es mir gerne wie eine Vererbung vor, bei der jedes Element in der Tabelle einige gemeinsame Eigenschaften (ID, Name) hat, aber unterschiedliche Datensätze unterschiedliche Eigenschaften haben können. Beispielsweise könnte ein Online-Produktkatalog Bücher, Fahrräder und MP3-Songs enthalten. Ein Datensatz für einen „Buch“-Artikel würde Dinge wie ISBN, Seitenzahl, Autor usw. enthalten. Ein „Fahrrad“ könnte Radgröße und -farbe haben, und ein „MP3“ würde Länge, Interpret, Genre usw. haben. Sie würden all diese Dinge niemals in einer "item"-Tabelle in anRDS erhalten, ohne ernsthafte Überladungen oder leere Felder zu hinterlassen. Eine NoSQL-Datenbank würde es Ihnen ermöglichen, all diese Informationen in der Tabelle zu speichern, und zwar nur für die Elemente, die sie benötigen.
Sie können das Schema, das Sie in Ihre Frage einschließen, auf jeden Fall mithilfe der Indizierungsfunktionen von Dynamo erstellen, aber Sie würden versuchen, eine NoSQL-Datenbank dazu zu bringen, sich wie ein RDS zu verhalten.
Das heißt:Ich selbst würde es als Lernerfahrung zuerst mit Dynamo versuchen. :)
