对于有用户的网站。每个用户都可以创建任意数量的帖子,我们将其称为“帖子”:
效率方面 - 为所有帖子创建一个表,为每个帖子保存创建帖子的用户的用户 ID,或者为每个用户创建不同的单独表并将创建的帖子放在那里更好由那个用户?
对于有用户的网站。每个用户都可以创建任意数量的帖子,我们将其称为“帖子”:
效率方面 - 为所有帖子创建一个表,为每个帖子保存创建帖子的用户的用户 ID,或者为每个用户创建不同的单独表并将创建的帖子放在那里更好由那个用户?
当您向其中添加更多数据时,数据库布局不应更改,因此用户数据绝对应该在一个表中。
还:
拥有多个表意味着您必须动态创建查询。
一个表的缓存查询计划不会用于任何其他表。
在一个表中有很多数据不会对性能产生太大影响,但是有很多表会影响性能。
如果你想为表添加索引以加快查询速度,那么在单个表上做会容易得多。
很好地回答具体问题:就查询效率而言,拥有小表总是更好,因此每个用户一张表可能是最有效的。
但是,除非您有很多帖子和用户,否则这可能并不重要。即使有数百万行,您也可以通过放置良好的索引获得良好的性能。
我强烈建议不要使用每用户表策略,因为它会为您的解决方案增加很多复杂性。例如,当您需要查找在一年内发布过某个主题的用户时,您将如何查询?
需要时进行优化。不是因为您认为/害怕某些事情会变慢。(即使您需要优化,也将有比每用户表更简单的选项)
具有不同数量表的模式通常很糟糕。为您的帖子使用一个表格。
如果性能是一个问题,您应该了解数据库索引。虽然索引不是 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,那么无论我们使用何种解决方案,我都看不出缓存有什么帮助,因为每个用户都将搜索不同的信息。
有什么想法吗?