mysql – 数据库设计:多个表与单个表

我正在建立一个网站,其中有不同类型的项目,如博客,帖子,文章等.用户可以将他们中的任何一个设置为他/她的最爱.现在当我接近这个东西时,我有两个选择

  1. Make a table for user favorites for each type of object.
  2. 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将抄袭所有数据.
所以我会选择第一个,很多小桌子,多对多.

上一篇:由Android应用程序和网站共享的关系数据库-简单的方法


下一篇:python – 如何更快地实现贪婪集?