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:
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:
Thank you all in advance!!! :-)
In DynamoDB, the adjacency list design pattern enables you to combine multiple SQL-type tables into a single NoSQL table. It has multiple uses but in this case can model many-to-many relationships. To do this, the partition key contains both types of item – races and racers.
However, you can model many common relational designs in a single DynamoDB table but the process is different using a NoSQL approach. This blog post uses the Alleycat racing application to explain the benefits of a single-table DynamoDB table. It also shows how to approach modeling data access requirements in a DynamoDB table.
When different entities of an application have a many-to-many relationship between them, the relationship can be modeled as an adjacency list. In this pattern, all top-level entities (synonymous to nodes in the graph model) are represented using the partition key.
Amazon DynamoDB is a highly performant NoSQL database that provides data storage for many serverless applications. Unlike traditional SQL databases, it does not use table joins and other relational database constructs.
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.
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.
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!
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With