搜索特定表是否比搜索特定表中的特定条目更快？答案

【问题标题】：Is searching for a specific table faster than searching for a particular entry in a particular table?搜索特定表是否比搜索特定表中的特定条目更快？
【发布时间】：2011-09-13 23:17:49
【问题描述】：

我需要为特定资源创建一个历史表，并试图决定如何设计它。我目前的想法是为资源的每个实例创建一个单独的表，并在有新添加的内容时输入一个新值。那会更快吗？还是我应该尝试将所有内容放在一张表中并进行搜索？我不太确定如何将它放在一张桌子上，但我想知道是否会出现速度冲击将是一个好的开始。

【问题讨论】：

标签： ruby-on-rails database sqlite database-design postgresql

【解决方案1】：

如果数据在逻辑上属于一张表，则放在一张表中。除非有充分的理由，否则不要过早地对数据进行垂直或水平分区。

【讨论】：

不过，按照您的建议往往会使唯一键变得不必要地复杂。通常最好在单独的表中实现活动行。
我同意 Denis 的观点，并补充说存储当前和历史信息的表具有不同的谓词（不同的含义），这是理论上的危险信号。（一个危险信号应该警告你不要将两者合并到一个表中，也就是说。）对我来说，“不同的谓词”是一个很好的理由。

【解决方案2】：

您似乎在寻找acts_as_audited。

【讨论】：

【解决方案3】：

如果您有历史记录，那么有一个类似...的表格就足够简单了。

history_id | resource_id | history_event
1          | 1           | created
2          | 1           | updated with silly info

使用resource_id 上的索引会非常快。 :)

【讨论】：

谢谢！知道在创建资源的新实例时如何在 Rails 中创建新的 resource_id 吗？我正在考虑使用全局变量，但我认为模型无法访问它。无论哪种方式，我都希望有更好的解决方案
您的资源在存储到数据库或使用Resource.create 方法时会自动分配一个ID。 :)
对，但据我了解，每一行都会被赋予一个新的 id。我需要资源的每个实例的 id，因此每次有新更新时该 id 应该能够重复。
对。 history_id 是主键，因此每次获得新行时都是完全唯一的。 resource_id 在这种情况下不是唯一的。您将拥有自己的resource 表，其主键为resource_id，因此当您进入该表时，每次插入都会获得一个新的resource_id。这有意义吗？