3.6: Overloading keys and indexes
One unique quirk of modeling with DynamoDB is that you will often include different types of entities in a single table.
Refer to the table below
| Primary Key | Attributes | ||||||
|---|---|---|---|---|---|---|---|
| Partition key: PK | Sort key: SK | OrgName | UserName | SubscriptionLevel | Role | ||
| "ORG#BERKSHIRE" | "ORG#BERKSHIRE" | "Berkshire Hathaway" | "" | "Enterprise" | "" | ||
| "ORG#BERKSHIRE" | "USER#CHARLIEMUNGER" | "" | "Charlie Munger" | "" | "Member" | ||
| "ORG#BERKSHIRE" | "USER#WARRENBUFFETT" | "" | "Warren Buffett" | "" | "Admin" | ||
| "ORG#FACEBOOK" | "ORG#FACEBOOK" | "Facebook" | "" | "Pro" | "" | ||
| "ORG#FACEBOOK" | "USER#SHERYLSANDBERG" | "" | "Sheryl Sandberg" | "" | "Admin" | ||
First, notice how generic the names of the partition key and sort key are. Rather than having the partition key named 'OrgName', the partition key is titled PK, and the sort key is SK. That’s because this table also has User items, and Users don’t have an OrgName. They have a UserName.
Second, notice that the PK and SK values have prefixes. The pattern is ORG#<OrgName> or USER#<UserName>. We do this for a few reasons. First, it helps to identify the type of item that we’re looking at. Second, it helps avoid overlap between different item types in a table. Remember that a primary key must be unique across all items in a table. If we didn’t have this prefix, we could run into accidental overwrites.
This concept of using generic names for your primary keys and using different values depending on the type of item is known as overloading your keys.