对于有用户的网站。每个用户都可以创建任意数量的帖子，我们将其称为“帖子”：
效率方面 - 最好为所有帖子创建一个表格，为每个帖子保存创建帖子的用户的用户 ID - 还是创建一个不同的单独 表格对于每个用户，只放该用户创建的帖子？
【问题讨论】：
[database] "table for each"这个词在这个网站上搜索一长串关于这个问题的不同看法。
posts(user_id) 或类似的索引。如果您有一个架构和一些需要快速运行的示例查询，最好告诉我们该架构和那些查询，并询问我们应该存在哪些索引。
标签： sql database processing-efficiency
当您向其中添加更多数据时，数据库布局不应更改，因此用户数据绝对应该在一个表中。
还有：
拥有多个表意味着您必须动态创建查询。
一个表的缓存查询计划不会用于任何其他表。
一个表中有很多数据不会对性能产生太大影响，但有很多表会影响性能。
如果您想为表添加索引以加快查询速度，那么在单个表上执行会容易得多。
【讨论】：
好回答具体问题：就查询效率而言，拥有小表总是更好，因此每个用户一张表可能是最有效的。
但是，除非您有 很多 帖子和用户，否则这可能无关紧要。即使有数百万行，您也可以通过放置良好的索引获得良好的性能。
我强烈建议不要使用每用户一张表的策略，因为它会为您的解决方案增加很多复杂性。例如，当您需要查找一年内在某个主题上发帖的用户时，您将如何查询？
在需要时进行优化。不是因为您认为/害怕某些事情会变慢。 （而且即使你需要优化，也会有比 table-per-user 更简单的选项）
【讨论】：
具有不同数量表的架构通常很糟糕。为您的帖子使用一个表格。
【讨论】：
如果性能是一个问题，您应该了解数据库索引。虽然索引不是 SQL 标准的一部分，但几乎所有数据库都支持它们以帮助提高性能。
我建议您为所有用户的帖子创建一个表，然后为该表添加索引以提高搜索性能。例如，您可以在user 列上添加索引，以便您可以快速找到给定用户的所有帖子。您可能还需要考虑添加其他索引，具体取决于您的应用程序的要求。
【讨论】：
您的第一个建议是拥有一个 user 和一个 post 表是标准方法。
目前，帖子可能是您网站上唯一特定于用户的功能，但想象一下，它可能需要在未来发展，以支持拥有消息、偏好等的用户。现在，您的每个用户单独的表格方法领先您需要创建的表数量激增。
【讨论】：
我对您的回答有类似但不同的问题，因为 @guffa 和 @driis 都假设“帖子”需要在用户之间共享。
在我的特殊情况下：出于隐私原因，不能与任何其他用户共享单个用户数据点，甚至不能用于分析。
我们计划使用 mysql 或 postgres，以下是我们团队正在争论的三个选项：
N 架构和 5 个表 - 我们的一些开发人员认为这是保持数据完全隔离的最佳方向。 优点 - 如果您将架构视为文件夹而将表视为文件，那么复杂性会降低。我们将为每个用户提供一个架构 缺点 - 大多数 ORM 为每个模式进行连接池
1 模式和 nx5 表 - 一些开发人员喜欢这样，因为它允许连接池，但似乎使问题更加复杂。 优点 - ORM 中的连接池是可能的 缺点 - 找不到为此设置模型的 ORM
1 个架构和 5 个表 - 一些开发人员喜欢这样，因为他们认为我们从缓存中受益。
优点：ORM 很高兴，因为这是它们的设计初衷 缺点：每个查询都需要用户名表
我个人进入 1 号营地：n 模式。 我的首席开发人员进入了 3 号营地：1 个架构 5 个表。
缓存： 如果数据始终是 1:1，那么无论我们使用哪种解决方案，我都看不出缓存有什么帮助，因为每个用户都会搜索不同的信息。
有什么想法吗？
【讨论】：