我正在制作一个网站，其中包含不同类型的项目，例如博客、帖子、文章等。用户可以将其中任何一个设置为他/她的最爱。现在当我接近这件事时，我有两个选择
- 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 1st one entails multiple database queries, and the second one entails a large single table.
如果有帮助，我正在使用 MySql
最佳答案
您似乎已经知道答案，但请记住，保持您设计的系统易于修改，因为业务模型总是会随着时间而变化，否则最终会失败(这是一种概括，但您明白了)。一个推论是，如果你制作一个僵化的模型，无论是快的还是慢的，它都是僵化的，改变会更加困难，最终用户不会看到差异，因此不会实现金钱/幸福的改变，除非这是一个非常糟糕的改变。 您的问题在查询在引擎上工作的方式上不是技术性的，而是更多的哲学问题，简单的更改与明显的速度。 问问自己，拥有标准化数据库的优势是什么？想想一个干净的架构和设计，性能是当今世界上最少的问题，因为处理更便宜，存储也更便宜。但是设计很昂贵。 进行规范化是为了使系统不依赖于最后一刻的决策，而是依赖于结构化的设计过程。 大表对 MySql 来说没什么大不了的，但它们对于维护、修改和扩展来说是一件大事。这不仅仅是增加一列，而是关于数据本身的刚性结构。最终，您将只添加包含索引的列，这些索引将指向小表。无论如何，MySql 将围绕所有这些数据进行探索。 所以我会选择第一个，很多小 table ，多对多。
关于mysql - 数据库设计 : Multiple tables vs a single table，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/9021838/