数据库效率-每个用户一个表vs用户表

Question

对于一个拥有用户的网站，每个用户都有创建任意数量帖子的能力：

在效率方面，是将所有帖子创建一个表格，并为每个帖子保存创建该帖子的用户ID，还是为每个用户创建一个不同的独立表格，仅将该用户创建的帖子放在其中更好？

- Yuval A.

---

在这个网站上使用术语[database] "table for each"搜索，可以找到很多关于这个问题的不同解决方案。 - Mat

如果需要快速获取给定用户的帖子，请在 posts(user_id) 或类似字段上创建索引。如果您有一个模式和一些需要快速运行的示例查询，最好告诉我们该模式和这些查询，并询问我们应该存在哪些索引。 - Dan D.

Answer 1

当您向数据库添加更多数据时，数据库布局不应更改，因此用户数据应该放在一个表中。

另外：

• 有多个表意味着您必须动态创建查询。

• 一个表格的缓存查询计划将不会用于任何其他表格。

• 在一个表格中有很多数据并不会对性能产生太大影响，但是拥有很多表格会影响性能。

• 如果想要为表格添加索引以加快查询速度，单个表格上的操作会更加容易。

- Guffa

Answer 2

回答具体问题，就查询效率而言，拥有小型表格肯定更好，因此按用户分表可能是最有效的。

但是，除非您有大量帖子和用户，否则这不太重要。即使有数百万行数据，只要正确放置索引，性能仍然很好。

我强烈反对按用户分表的策略，因为它会给解决方案增加很多复杂性。当您需要查找例如在一年内发布过某个主题的用户时，该如何查询？

需要优化时再进行优化，不要因为觉得或怕某些东西会运行缓慢而进行优化（即便需要优化，也有比按用户分表更简单的选项）。

- driis

---

我不同意“总是”的说法 - 给我每个用户的所有帖子计数。编写一个将对此进行聚合的UNION查询既不有趣，也不高效。 - Aaron Bertrand

你可以使用一个视图来实现这个。 - malhal

需要时进行优化，而不是因为你认为/担心某些东西会变慢。我喜欢它！ - OhhhThatVarun

有没有所谓的过度优化？我认为在事情还很小的时候优化是一个好主意，而不是等待事情变得庞大，然后决定需要优化并且必须重构大量的代码/查询。我认为从优化的角度出发是一个更好的想法。 - c0dezer019

@c0dezer019，有一种叫做“过早”优化的东西。大多数人不需要为自行车建造一个小屋，如果他们忙于“自行车棚”，他们也无法完成房屋的翻新。始终先进行测量，然后解决已被证实的瓶颈问题。 - MeetTitan

Answer 3

通常情况下，拥有不同数量表格的模式是不好的。在您的帖子中使用单个表格。

- Mat

Answer 4

如果性能是一个问题，你应该了解数据库索引。虽然索引不是SQL标准的一部分，但几乎所有的数据库都支持它们以帮助提高性能。

我建议您为所有用户的帖子创建一张单独的表，并在此表上添加索引以改善搜索性能。例如，您可以在user列上添加一个索引，这样您就可以快速查找给定用户的所有帖子。根据您的应用程序要求，您可能还需要考虑添加其他索引。

- Mark Byers

Answer 5

你的第一个建议是采用单一的user和单一的post表，这是标准的做法。

目前，帖子可能是你网站上唯一与用户相关的功能，但请想象一下未来它可能需要扩展以支持用户拥有消息、偏好设置等。现在你分别使用每个用户的表的方法会导致你需要创建大量的表。

- avik

Answer 6

我对你的回答有类似但不同的问题，因为@guffa和@driis都假设“帖子”需要在用户之间共享。

在我的特定情况下：出于隐私原因，不能与任何其他用户共享单个用户数据点，甚至不能用于分析。

我们计划使用mysql或postgres，以下是我们团队正在争论的三个选项：

N个模式和5个表 - 我们的一些开发人员认为这是保持数据完全隔离的最佳方向。 优点-如果您将模式视为文件夹，将表视为文件，则复杂性较小。我们将为每个用户拥有一个模式 缺点-大多数ORM会对每个模式进行连接池

1个模式和nx5个表 - 一些开发人员喜欢这种方式，因为它允许连接池，但似乎使问题更加复杂。 优点-ORM中可以进行连接池 缺点-找不到设置此类模型的ORM

1个模式和5个表 - 一些开发人员喜欢这种方式，因为他们认为我们从缓存中受益。

优点：ORM很高兴，因为这就是它们设计的方式 缺点：每个查询都需要用户名表

就编程而言，我个人属于第一派：n个模式。我的主要开发者属于第三派：1个模式5个表。

缓存： 如果数据始终是1:1，无论我们使用什么解决方案，我都看不出缓存如何有助于提高性能，因为每个用户都会搜索不同的信息。

有什么想法吗？

- Brian Becker

---

@guffa - 我不能将你的答案逻辑应用到我的问题上...那么，你能提供其他原因吗？ - Brian Becker