What are the advantages/disadvantages of creating a new set of tables for each user?

Question

I'm working/playing on an app where individual users' data will be completely independent from each other. Of course, there will be common tables for other parts of the app (e.g. "users"), but for the rest of the tables, would it be wise to create a new set of tables for each user?

e.g.

List of tables:
users
user1_transactions, user1_items, user1_tags
user2_transactions, user2_items, user2_tags

for a total of 7 tables for the 2 users.

Would I have trouble with migrations with this setup (assuming the condition that user data will always be independent)?

I don't have much experience with relational design, so I guess this is a "I don't know what I don't know" situation. Is this a bad idea?

Answer 1

It's a terrible idea to be honest and there are a handful of immediate issues with that I can think of off the top of my head:-

• modifying the table structure becomes very difficult because of the number of tables you need to modify.
• you have to grant rights the app to change the table structure which is opposite to the principle of 'least privilege'.
• you're mixing your data structure with your actual data which goes against the separation of concerns and mixes the design with the data.
• migration shouldn't be a major concern although you do need to make sure that table names are unique.

That's all before we get into any issues of performance or limits on the number of tables or consider the impacts of how Indexing, and Views which will be useless across these multiple tables.

You're better off sticking with:

Users
Transactions
Items
Tags

You might find some useful information about designing your tables properly in Is it necessary to create a database with as few tables as possible

Answer 2

Don't do this. Plain and simple, that's a terrible data tier pattern. It is bad for the following reasons:

• Doesn't scale well at all (rows should be created with new data, not objects)
• Data access patterns will suffer (it will be a pain, best case scenario, to construct your data queries. Worst case scenario you will cause extremely poor performance and other possible side effects)
• Not maintainable (it will be, again, a pain to even figure out creation and maintenance on things like indexes and statistics)
• Lack of data rigidity (think about it, there is no enforced construct to say that all user transaction tables will have the same columns, data types, etc. You could find yourself in a data consistency/purity problem quite quickly)

I haven't even brought up relational design and how this doesn't subscribe to the accepted constructs there. But hopefully the supportability and programmability nightmare is enough to steer you away from this direction.

Not to mention... it's just hard. Why make it more difficult on yourself, as the model of common tables for common data is just so simple and natural.

Answer 3

Your solution is not relational and has a lot of disadvantages, to name a few:

• nearly impossible to do some queries involving data for multiple users
• no constraints can be used, therefore no consistency of your data
• hard to deal with privileges
• hard to migrate (if user ID is somehow changes, you're done)

There probably should be those tables:

• users, having id field
• transactions, items, and tags tables, all having user_id field which point to users.id - this is called "one-to-many relation", since each user can have multiple transactions, items and tags.

If, for example, tags can be shared between users, you should instead have tags table just have id, and also a table users_tags with two fields: user_id and tag_id, which connects users and tags with many-to-many relation.

You have to learn at least basics of database normalization and RDBMS in general before even attempting to design a schema. Database design is moderately difficult (depending on a task) topic, not something you can start with in couple of days.