DynamoDB M-M Adjacency List Design Pattern

Referring to amazon. I was wondering if anyone could help me.

The first image is of the table, and the second is the GSI. Here is the table: here

On the table, I don't understand how one is to create the sort-key? Is this one attribute that stores both Bill-ID and Invoice-ID? or two separate attributes? I have a feeling it's the one flexible attribute, and if so how do you differentiate one from the other? And how are we meant to construct the query on the sort-key?

Is it just by looking the prefix "Bill-" or "Invoice-"? The practice of DynamoDB seems to make use of dashes ("-") to separate values in an attribute. If anyone can give me use cases of such things, I would be grateful as well, but I am going off tangent unless it's important in this case.

Now, this is very relatable and very interesting YouTube, where the presenter uses ONE product table to store various types of items: Books, Song Albums, and Movies; and each has their own attributes.

Again I have a problem understanding the sort-key used there. I understand that productID=1 is bookID, and productID=2 is an Album. Now where it gets confusing now is what I circled in red. These are the tracks of Album 2. However, the structure of the sort key is "albumID:trackID". Now, where is the "trackID"? Is it meant to substitute the word "trackID" with actual ID? or is this meant to be a text exactly as "albumID:trackID"?.

What if I wanted to query a specific trackID? what would be the syntax of my query?

Please see the image here from the youtube: enter image description here

Thank you all in advance!!! :-)


Solution 1:

In the first picture you posted the items in the base table (primary key) would look like this:

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

And the same items in the GSI the items would look like this

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
Bill-4224663                   Bill-4224663
Bill-4224687                   Bill-4224687 

They have drawn it in quite a confusing way.

  • They have merged the partition keys into one box, but they are separate items.
  • They have also tried to show the GSI in the same picture. You can think of the base table and the GSI as two separate tables that are kept in sync, in many ways that's what they are.
  • They haven't actually provided a name to the key attributes. In my example I have named them First_id and Second_id.

When you do a query on the base table, you can use a query with the partition key Invoice-92551 and you get both the Invoice item plus all the bill items that belong to it.

Imagine you are viewing invoice Invoice-92551 in an application and you can see it has two associated bills (Bill-4224663 and Bill-4224687). If you clicked on the bill, the application would probably do a query on the GSI. The GSI query would have partition key Bill-4224687. If you look at the GSI table I have drawn above, you can see this will return two items, showing that Bill-4224687 is part of two invoices (Invoice-92551 and Invoice-92552)


In your second picture, the words 'bookID' and 'albumID' etc are supposed to represent actual IDs (lets say 293847 and 3340876).

I would draw his example like this:

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:Actor2                    Maya Rudolph

Here are your queries:

Partition key: Album1

Gives you ALL the information (inc tracks) on Album 1 (Dark Side)

Partition key: Album1 and Sort Key: Album1:Track2

Gives you just the information on Breathe.

Partition key: Movie8

Gives you ALL the information (inc actors) on Movie8 (Idiocracy)

If I was building the table I would make it so the words Movie, Album etc were part of the actual ID (say Movie018274 and Album983745987) but that's not required, it just makes the IDs more human readable.

Solution 2:

Stu's answer is not quite correct, the table actually looks as it is illustrated:

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

In the table above, the Bill items (i.e. partition key = Bill-xxxxx) hold common information for the bill, where as the Invoice items with Bill items as sort key hold information for the bill that is specific to the given invoice.

In order to fully reconstruct a bill, a GSI is required that allows you to lookup the complete information for a bill (i.e. the common record + invoice specific records):

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!