I have a basic web app where with the following hierarchy being persisted
>User1 >Client1 >ID >Name >Profession >Client2 >ID >Name >Profession >User2 >Client1 >Favorite Meal >Favorite TV Show >Favorite Animal >Client2 >Favorite Meal >Favorite TV Show >Favorite Animal
So basically, each users have clients and each user's clients have different fields that I want to persist. Under a single user, all the clients will have the same structure. So what I'm doing is persisting each user with nested clients in it's own document within a
What bugs me now is I do not know what design would be good for the following feature :
I want my Users to be able to change the fields that are persisted. So if I take the example above,
User1 could remove the
ID field if he doesn't need it anymore and replace it with anything else or simply not replace it at all.
1 - Should I allow my user to be able to modify the design or is that a bad idea from the get go ?
2 - If it is not a bad idea, how should I handle these changes when they are made? Should I simply (I know I'm referring to columns but these are my old relational habits)
- Delete a column when a column is deleted
- Rename a column when is is renamed
- Add a column when it is added and let all the old entries have
nullas a value for this new column
Or should I create a new document every time a modification is made to the data of a user and try to move all the data that fits from the old document into the new one. Then delete the old document.
Are there any other good design patterns that could apply.