MySQL 多表或少表答案

【问题标题】：MySQL many tables or few tablesMySQL 多表或少表
【发布时间】：2011-10-05 07:32:22
【问题描述】：

我正在构建一个非常大的网站，目前它使用大约 13 个表，到完成时应该是大约 20 个。

我想出了一个想法，将首选项表更改为使用 ID、键、值而不是许多列，但是我最近认为我也可以在表中存储其他数据。

将几乎所有内容都存储在一张表中是否高效/智能？

编辑：这里有更多信息。我正在建立一个可能最终拥有数千名用户的社交网络。 MySQL 集群将在站点启动时使用，现在我正在使用开发 VPS 进行测试，但是所有内容都将在启动前移动到专用服务器。我对 NDB 几乎一无所知，所以这应该很有趣 :)

【问题讨论】：

【解决方案1】：

这个模型叫做EAV（实体-属性-值）

它适用于某些场景，但由于记录较大、数量或连接较多以及无法在多个属性上创建复合索引，因此效率较低。

基本上，它用于实体具有大量极其稀疏（很少填充）和/或在设计时无法预测的属性，例如用户标签、自定义字段等。

【讨论】：

EAV 的主要缺点是您不能轻松地强制执行数据域（例如，确保 autorized_ip_address 是有效的 IP 地址，percentage 介于 0 和 100 之间或 birthday 是日期）。但是，MySQL 无论如何都没有检查约束...
EAV 的主要缺点是大约有3251 的缺点。

【解决方案2】：

虽然我对大型数据库设计了解不多，但据我所知，即使是非常大的应用程序存储它们的东西也是非常少量的表（每个表 20GB）。

对我来说，我宁愿在 1 个表中包含更多信息，因为这意味着数据不会到处乱扔，而且我不必对多个表执行操作。虽然 1 个表也意味着混乱（通常对我来说，每个对象都会放在表上，而对象是您在应用程序逻辑中拥有的东西，例如 User 类或 BlogPost 类）

我想我想说的是，做任何有意义的事。不要将同一事物的信息放在 2 个不同的表中，也不要将 2 个事物的信息放在 1 个表中。坚持一张表只描述某个对象（这个很难解释，但是如果你做面向对象的，你应该明白。）

【讨论】：

【解决方案3】：

不。首选项应按原样存储（在用户表中）例如私人消息不能存储在用户表中......

您不必考虑加入不同的表格...

【讨论】：

我应该将个人资料/首选项存储在一个表中，然后将朋友存储在另一个表中。消息已存储在不同的表中。
我就是这么想的，除了朋友。还有一个用于friend_requests 的表。至于消息，有两个表，一个用于帖子，另一个用于参与者（因为可以有多个）。
如果你的friends表有超过100 000行，firends_requests应该在friends_requests中，但是你可以把它放到friends表中并且状态为“接受” -1（还没有）0（忽略）1 （接受）
该站点可能有超过一百万的用户，所以我将保留 2 表系统供朋友使用。现在它将为 1 友谊制作 2 行：1 朋友与 2，2 朋友与 1。这可以改变吗？我尝试让 MySQL 在两列上只需要 1 行，但这会导致很多问题。

【解决方案4】：

我首先要说 20 张桌子并不多。

总的来说（从您提供的有限信息中很难说）键值模型在速度方面效率不高，尽管它在空间方面可能更有效。

【讨论】：

我的应用目前有... 169 个表，而且肯定会有更多。诚然，它不是一个网站，而是一个 CRM，但 20 个表仍然不是那么多。
该网站是一个社交网络。我不确定它会走多远，但我们最终可能会拥有数千个帐户。虽然我们将拥有 MySQL 集群，但我不知道该怎么做才能提高性能。我从来没有解决过这么大的问题。
@user683812 也许 MySQL（或一般的关系数据库）不是您所需要的？以 MongoDB 等文档数据库为例。
哪些必需的任务会带来性能问题？如果您能具体一点，也许我们可以提供帮助。
目前 MySQL 几乎可以处理所有事情，包括身份验证。我选择不使用 PHP 的会话管理器，因为如果服务器出现故障，用户可以连接到另一个服务器。仅加载主页将导致至少 100 个 SQL 查询。我认为当有成千上万的用户交互时，这可能会很多。还有大量广泛使用 AJAX，几乎所有 AJAX 都将使用多个表和许多 SQL 查询。只需在主页上停留 5 分钟即可获得近 500 个查询。

【解决方案5】：

我绝对不会这样做。基本上，原因是如果您将大量数据存储在单个表中，当不断查询同一个表时，您会很快看到性能问题。然后考虑您将需要的查询的连接和复杂性（取决于您的站点）......这不是我个人愿意承担的任务。

通过使用多个表，它将数据拆分为更小的集合，查询所需的资源更少，而且作为额外的奖励，它更容易编程！

有一些应用程序可以做到这一点，但它们很少见，如果您有一个包含大量列的大表并且大多数都没有价值，那么它们或多或少是罕见的。

我希望这会有所帮助:-)

【讨论】：

这么多桌子？有一个大的偏好，另一个大的朋友，另一个用于个人资料信息。所有人都应该分开对吗？使用 PHP 链接数据。
使用你需要的表，一般来说数据库的最佳实践是对相似的数据集进行“分组”，你的表可能是 user_info、messages、user_config、site_config、activity_log 所有这些数据都被分组与其他性质相似的数据。例如，您将在 mySQL 中使用 JOIN 来获取带有消息数据的正确 user_info，然后您可以使用 PHP 或 JS 随意操作数据。您会注意到一个名为 activity_log 的表，这是使用 id、key 和 value 的一个很好的例子，因为您可以记录 1,000 种类型的操作并且不需要 1,001 个字段
抱歉，直接回答您的问题 - 是的，请将它们分开 :-)

【解决方案6】：

我认为一个项目中的 20 个表并不多。我确实看到您对使用 EAV 的观点和兴趣，但我认为没有必要。我会坚持使用具有适当 FK 关系等的 3NF 表，你应该没问题 :)

【讨论】：

【解决方案7】：

简单的答案是 20 个表不会使它成为一个大数据库，而 MySQL 不需要为此进行任何优化。因此，请专注于干净的数据库结构和规范化。

【讨论】：