Database Reference
In-Depth Information
as for Table 1.9 and Table 1.10 are invalid because the hash and range keys must be either
String , Number , or Binary . It cannot be Set . We will discuss the Set data type at
the end of this chapter.
Once you have had a good look at a valid table schema, you will have the following ques-
tions for sure:
• What is the difference between the hash key and the range key?
• What is the difference between String data type and StringSet data type?
• Apart from Set , is there any other data type that I should know about?
• During table creation, what mandatory information should I provide?
Let us discuss the answers to these questions, which will help us understand the Dy-
namoDB data model better. Here comes the answer to the first question. With the hash
and range keys, hash and range are two attributes that act like a (compound) primary key.
The range key must be accompanied by the hash key, but the hash key can optionally be
accompanied by the range key. The hash key is an attribute that every table must have. It
is an unordered collection of items; this means that items with the same hash key values
will go to the same partition, but there won't be any ordering based on these hash key val-
ues, whereas items will always be ordered on range key values (but grouped on hash key
values). After applying the previous statements to the already-created table, its order will
look as follows:
So there is no guarantee that the table data will be sorted by the hash key (that is
BookTitle ), but it will be hashed or grouped based on the hash key attribute value.
That is the reason why Item1 and Item4 are placed close together. On the other hand,
the records are ordered on the range key (that is, Author ). That is the reason why the
Search WWH ::




Custom Search