I am using AWS dynamodb for my project.
One can choose to use a simple key (partition key alone) or a composite key (partition key + range key) when creating a dynamo db table. But once it is created, the decision is baked in.
For example, if a table was created with a partition key alone, and I need to add a range key due to new business need, the only possible way is by dropping the table and then recreate it with a new key structure.
It will be a major hassle to recreate a table like this. After all if I want to use dynamodb, holding a lot of data will be the primary motive. It is impractical to recreate table to add a range key.
So, as a design question, does it make sense to:
Always add a range key to an AWS dynamo db table design, even though there is no such need at the time of requirement analysis, to future proof the table design.
The dummy range key can reuse the partition key value at the beginning. It is a minor innocence in coding, but it may offer more resilience in the future.
Is it a sound strategy?