1
votes

For what I'm understanding, dynamodb has two ways for defining primary keys: Single primary keys that only use the partition key and composite keys that needs to specify both a partition key and a sort key.

The thing I'm stuck right now is that I'm not sure if for this case a users table should have a single primary key or a composite.

Here for example says that a good example for a single primary key is the users table, but I'm not sure how true it is.

1
This is not conclusive for making a decision. It all depends on your access patterns to this table. If you only want to get a user with their id, then yeah primary key of userId is enough. This is the most common access pattern for users. But you probably have other needs like querying most active users, users that has a , say, car etc etc etc. For these you might use GSIsCan Sahin

1 Answers

0
votes

As a general rule, you could promote as the primary key the user's email and make it as a partition key.

When I faced the same problem I made it using 2 tables:

On the table 1 I had all user data, like:

LICENSE_NUMBER, NAME, EMAIL, PASSWORD, ETC... where "LICENSE_NUMBER" is the primary key which is mainly used to identify the user when needed.

...And I also had a table 2 having the following fields:

EMAIL, LICENSE_NUMBER, ETC... where "EMAIL" is used to retrieve the "LICENSE_NUMBER" when the user logs in.

Final consideration:

Since DynamoDB does not allow JOIN operations I had to split in two tables and emulate a join by creating 2 tables with single primary keys each, but tied to the same Email / Licence_number fields.

Hope this helps you when choosing the right pattern to build your user table.