J'ai beaucoup travaillé avec les bases de données relationnelles et un peu avec les bases de données NoSQL (juste pour que vous sachiez d'où je viens). À mon humble avis, les bases de données NoSQL sont mieux adaptées aux scénarios où un ou plusieurs sont vrais :
- Les données sont essentiellement plates (pas beaucoup de relations, presque comme un vieux fichier plat)
- Il existe un enregistrement de type "parent" défini avec des enregistrements "enfants" qui sont suffisamment petits/accessibles assez fréquemment avec le parent pour justifier de les intégrer directement dans l'enregistrement.
- Vous avez besoin de la liberté d'ajouter/remplir des champs dans des limites raisonnables. J'aime y penser comme un héritage, où chaque élément de la table partage certains traits communs (ID, nom), mais différents enregistrements peuvent avoir des traits différents. Par exemple, un catalogue de produits en ligne peut contenir des livres, des vélos et des chansons MP3. Un enregistrement pour un élément "livre" contiendrait des éléments tels que l'ISBN, le nombre de pages, l'auteur, etc. Un "vélo" pourrait avoir la taille et la couleur des roues, et un "MP3" aurait la longueur, l'artiste, le genre, etc. Vous n'obtiendrez jamais toutes ces choses dans une table "élément" dans anRDS sans une surcharge sérieuse ou en laissant des champs vides. Une base de données NoSQL vous permettrait de stocker toutes ces informations dans la table, et uniquement pour les éléments qui en ont besoin.
Vous pouvez certainement créer le schéma que vous incluez avec votre question en utilisant les capacités d'indexation de Dynamo, mais vous essaieriez de faire en sorte qu'une base de données NoSQL agisse comme un RDS.
Cela dit:je l'essayerais moi-même d'abord avec Dynamo comme expérience d'apprentissage. :)
