数据库设计：多个表与单个表

Question

我正在建立一个网站，其中包含不同类型的项目，例如博客，帖子，文章等。用户可以将其中任何一个设置为他/她的最爱。现在，当我处理这个问题时，我有两个选择

1. 为每种对象的用户收藏夹创建一个表。
2. 为所有用户的所有类型的对象创建一个公用表。
   
   

第一种结构的问题是，我将不得不查询很多表以显示特定用户的收藏夹。但这将使我可以轻松地将收藏夹分为不同的类别。

但是，如果我必须在一个页面上显示所有收藏夹并将它们全部合并（按时间排序），那么这将变得很困难。但是，如果使用第二种模型，则可以轻松获得最新的收藏夹，并且还可以根据对象类型对它们进行分组并不困难，但是我将在整个站点范围内拥有一个大表。

两种策略中的哪一种将更具可扩展性。

第一个需要多个数据库查询，第二个需要一个大的单个表。

如果有帮助，我正在使用 MySql

Answer 1

看来您已经知道了答案，但是请记住，要使设计的系统易于修改，因为业务模型总是随时间变化，否则它们最终会失败（这是一种概括，但您可以理解）。这样的推论是，如果您制作一个刚性模型，无论是快速还是慢速，它都是刚性的，更改都会更加困难，最终用户将看不到差异，因此除非有非常糟糕的更改，否则就不会实现金钱/幸福的变化。您的问题不是技术在引擎上工作的方式，而是技术上的问题，即简单的更改与明显的速度。问问自己，拥有标准化数据库有什么好处？考虑一下干净的体系结构和设计，在当今世界，性能是最不重要的问题，因为处理更便宜，存储也更便宜。但是设计很昂贵。进行标准化是为了使系统不依赖于最后的决策，而依赖于结构化的设计过程。大表对MySql来说不是什么大问题，但是对维护，html" target="_blank">修改和扩展来说，它们却很重要。这不仅仅是增加一列，还涉及数据本身的刚性结构。最终，您将及时添加包含索引的列，这些索引将指向小型表。无论如何，MySql都将围绕所有这些数据进行耕作。所以我会去第一个，很多小桌子，多对多。最终，您将及时添加包含索引的列，这些索引将指向小型表。无论如何，MySql都将围绕所有这些数据进行耕作。所以我会去第一个，很多小桌子，多对多。最终，您将及时添加包含索引的列，这些索引将指向小型表。无论如何，MySql都将围绕所有这些数据进行耕作。所以我会去第一个，很多小桌子，多对多。