I am making a website where there are different types of items such as blogs, posts, articles and so on. A user can set any one of them as his/her favorite. Now when I approach this thing, I have two options
- Make a table for user favorites for each type of object.
- Make a common table for all type of objects for all the users.
The problem with the 1st structure is that I will have to query a lot of tables for displaying the favorites of a particular user. But it will allow me to easily group the favorites into different categories.
However if I have to show all the favorites on one single page and merge them all, sorted according to time, then that becomes difficult. But if I use the second model, I can easily get the latest favorites, and also grouping them according to object type is not difficult, but I will have one large table site wide.
Which of the two strategies will be more scalable.
The 1st one entails multiple database queries, and the second one
entails a large single table.
If it helps, I am using MySql
It seems that you already know the answer, but remember, keep the systems you design simple to modify as business models always change over time or they eventually fail (it’s a generalization but you get the idea). A corollary of that is if you make a rigid model, fast or slow, it’s rigid, changes will be harder and the end user won’t see the difference, hence no money/happiness change is achieved, unless it’s a very bad change.
Your problem is not technical in a way a query works on the engine but more of a philosophical one, easy changes versus apparent speed.
Ask yourself, what’s the advantage of having a normalized database? Think about a clean architecture and design, performance is the least problem in todays world as processing is cheaper and storage also. But design is expensive.
Normalization was made to make systems that don’t depend on last moment decisions but on a structured design process.
Big tables are not a big deal for MySql but they are a big deal to maintain, modify and expand. It’s not just adding one more column, it’s about the rigid structure of the data itself. Eventually in time you will just add columns that contain indexes, and those indexes will be pointing to small tables. MySql will be plowing it’s way around all that data anyway.
So i’ll go for the first one, a lot of small tables, many-to-many.