Modèle de conception de liste d’adjacence DynamoDB M-M
En vous référant à https://docs.aws.Amazon.com/amazondynamodb/latest/developerguide/bp-adjacency-graphs.html . Je me demandais si quelqu'un pourrait m'aider.
La première image est de la table et la seconde est le GSI. Voici le tableau: 
Sur la table, je ne comprends pas comment créer la clé de tri? Est-ce que cet attribut stocke à la fois Bill-ID et Invoice-ID? ou deux attributs distincts? J'ai l'impression que c'est l'unique attribut flexible, et si oui, comment différenciez-vous l'un de l'autre? Et comment sommes-nous censés construire la requête sur la clé de tri?
Est-ce juste en cherchant le préfixe "Bill-" ou "Invoice -"? La pratique de DynamoDB semble utiliser des tirets ("-") pour séparer les valeurs d'un attribut. Si quelqu'un peut me donner des exemples d'utilisation de ce genre de choses, je lui en serais également reconnaissant, mais je me moque de moins en moins, à moins que ce soit important dans ce cas.
Maintenant, c’est très intéressant et très intéressant https://youtu.be/xV-As-sYKyg?t=1897 , où le présentateur utilise UNE table de produits pour stocker différents types d’articles: Livres, Albums de chansons, et des films; et chacun a ses propres attributs.
Là encore, j'ai du mal à comprendre la clé de tri utilisée ici. Je comprends que productID = 1 est bookID et productID = 2 est un album. Maintenant, là où cela devient confus, c’est ce que j’ai entouré en rouge. Ce sont les pistes de Album 2. Cependant, la structure de la clé de tri est "albumID: trackID". Maintenant, où est le "trackID"? Est-il censé remplacer le mot "trackID" par un identifiant réel? ou est-ce que cela est censé être un texte exactement comme "albumID: trackID"?.
Et si je voulais interroger un trackID spécifique? Quelle serait la syntaxe de ma requête?
S'il vous plaît voir l'image ici à partir de YouTube: 
Merci d'avance à tous!!! :-)
Dans la première image, vous avez posté les éléments de la table base (clé primaire) ressemblerait à ceci:
First_id(Partition key) Second_id(Sort Key) Dated
------------- ---------- ------
Invoice-92551 Invoice-92551 2018-02-07
Invoice-92551 Bill-4224663 2017-12-03
Invoice-92551 Bill-4224687 2018-01-09
Invoice-92552 Invoice-92552 2018-03-04
Invoice-92552 Bill-4224687 2018-01-09
Et les mêmes éléments dans leGSIles éléments ressembleraient à ceci
Second_id(Partition Key) First_id
---------- ---------------
Invoice-92551 Invoice-92551
Bill-4224663 Invoice-92551
Bill-4224687 Invoice-92551
Invoice-92552 Invoice-92552
Bill-4224687 Invoice-92552
Ils l'ont dessiné d'une manière assez déroutante.
- Ils ont fusionné les clés de partition dans une boîte, mais ce sont des éléments séparés.
- Ils ont également essayé de montrer le GSI dans la même image. Vous pouvez considérer la table de base et le GSI comme deux tables distinctes, synchronisées, à bien des égards.
- Ils n'ont pas réellement fourni de nom aux attributs de clé. Dans mon exemple, je les ai nommés First_id et Second_id.
Lorsque vous effectuez une requête sur la table de base, vous pouvez utiliser une requête avec la clé de partition Invoice-92551 et obtenir à la fois le poste de facturation et tous les postes de facture qui lui appartiennent.
Imaginez que vous visualisiez la facture Invoice-92551 dans une application et que vous voyiez deux factures associées (Bill-4224663 et Bill-4224687). Si vous cliquez sur la facture, l'application effectuera probablement une requête sur le GSI. La requête GSI aurait la clé de partition Bill-4224687. Si vous regardez la table GSI que j'ai dessinée ci-dessus, vous pouvez voir que cela renverra deux éléments, montrant que Bill-4224687 fait partie de deux factures (Invoice-92551 et Invoice-92552).
Dans votre deuxième image, les mots 'bookID' et 'albumID', etc. sont supposés représenter des identifiants réels (disons 293847 et 3340876).
Je dessine son exemple comme ceci:
ProductID(Partition Key) TypeID(Sort Key) Title Name
--------- ------ ------ ------
Album1 Album1 Dark Side
Album1 Album1:Track1 Speak to me
Album1 Album1:Track2 Breathe
Movie8 Movie8 Idiocracy
Movie8 Movie8:Actor1 Luke Wilson
Movie8 Movie8:Actor1 Maya Rudolph
Voici vos questions:
Partition key: Album1
Vous donne TOUTES les informations (pistes incluses) sur l'album 1 (Dark Side)
Partition key: Album1 and Sort Key: Album1:Track2
Vous donne juste l'information sur Breathe.
Partition key: Movie8
Vous donne TOUTES les informations (y compris les acteurs) sur Movie8 (Idiocratie)
Si je construisais la table, je ferais en sorte que les mots Film, Album, etc. fassent partie de l'identifiant réel (par exemple, Movie018274 et Album983745987), mais ce n'est pas obligatoire, cela rend simplement les identifiants plus lisibles par l'homme.
La réponse de Stu n'est pas tout à fait correcte, le tableau ressemble en réalité à l'illustration suivante:
First_id(Partition key) Second_id(Sort Key) Dated
------------- ---------- ------
Invoice-92551 Invoice-92551 2018-02-07
Invoice-92551 Bill-4224663 2017-12-03
Invoice-92551 Bill-4224687 2018-01-09
Invoice-92552 Invoice-92552 2018-03-04
Invoice-92552 Bill-4224687 2018-01-09
Bill-4224663 Bill-4224663 2018-12-03
Bill-4224687 Bill-4224687 2018-01-09
Dans le tableau ci-dessus, les postes de facture (c'est-à-dire clé de partition = Bill-xxxxx) contiennent des informations communes pour la facture, tandis que les postes de facture avec des postes de facture comme clé de tri contiennent des informations propres à la facture donnée.
Afin de reconstituer intégralement une facture, un GSI est nécessaire pour vous permettre de rechercher les informations complètes d'une facture (c'est-à-dire l'enregistrement commun + les enregistrements spécifiques à la facture):
Second_id(Partition Key) First_id Data
---------- --------------- -----------
Bill-4224663 Bill-4224663 Common bill data
Bill-4224663 Invoice-92551 Bill data for Invoice-92551
Bill-4224687 Bill-4224687 Common bill data
Bill-4224687 Invoice-92551 Bill data for Invoice-92551
Bill-4224687 Invoice-92552 Bill data for Invoice-92552
Invoice-92551 Invoice-92551 Redundant data!
Invoice-92552 Invoice-92552 Redundant data!