在 ActiveRecord 中存储序列化哈希与键/值数据库对象的优缺点？

Question

如果我有几个对象，每个对象基本上都有一个 Profile，我用什么来存储随机属性，以下优点和缺点是什么：

1. 在记录的列中存储序列化哈希，与在列中存储序列化哈希。
2. 存储一堆属于主对象的键/值对象。

代码

假设您有如下 STI 记录：

class Building < ActiveRecord::Base
  has_one :profile, :as => :profilable
end
class OfficeBuilding < Building; end
class Home < Building; end
class Restaurant < Building; end

每个 has_one :profile

选项 1. 序列化哈希

class SerializedProfile < ActiveRecord::Base
  serialize :settings
end

create_table :profiles, :force => true do |t|
  t.string   :name
  t.string   :website
  t.string   :email
  t.string   :phone
  t.string   :type
  t.text     :settings
  t.integer  :profilable_id
  t.string   :profilable_type
  t.timestamp
end

选项 2. 键/值存储

class KeyValueProfile < ActiveRecord::Base
  has_many :settings
end

create_table :profiles, :force => true do |t|
  t.string   :name
  t.string   :website
  t.string   :email
  t.string   :phone
  t.string   :type
  t.integer  :profilable_id
  t.string   :profilable_type
  t.timestamp
end

create_table :settings, :force => true do |t|
  t.string   :key
  t.text     :value
  t.integer  :profile_id
  t.string   :profile_type
  t.timestamp
end

您会选择哪一个？

假设 99% 的情况下我不需要通过自定义设置进行搜索。只是想知道在性能和未来出现问题的可能性方面有何权衡。自定义设置的数量可能在 10-50 之间。

我宁愿选择第二个选项，即设置表，因为它遵循 ActiveRecord 面向对象的约定。但我想知道在这种情况下是否会导致性能成本过高。

注意：我只是想知道 RDBMS 方面的问题。这非常适合 MongoDB/Redis/CouchDB/等。但我想纯粹了解 SQL 方面的优缺点。

Answer 1

我也有同样的问题，但最终还是做出了决定。

哈希序列化选项会带来维护问题。查询、扩展或重构此类数据很困难 - 任何细微的更改都需要迁移，这意味着读取每个记录反序列化和序列化回来，并且根据重构可能会发生序列化异常。
我尝试了二进制序列化和 JSON - 第二种更容易提取和修复，但仍然很麻烦。

我现在尝试使用单独的设置表 - 更容易维护。我计划使用 Preferences gem 来完成所有抽象以便于使用。我不确定它是否适用于 Rails 3 - 它很小，所以如果需要我可以扩展它。

2013 年 11 月更新

最近发布的 Rails 4 支持 PostgreSQL 9.1+ 的出色新功能，例如动态数据集的 hstore 或 json 列类型。这是一篇文章，涵盖 Rails 4 中的 hstore 使用。两种类型都支持索引和高级查询功能（Json with Pg 9.3）。 Rails 3 用户也可以使用 activerecord-postgres-hstore gem 来使用 Hstore。

我正在将项目中的一些非关键首选项表迁移到 hstores。在迁移中，我只需更新表定义并为每个表执行一个 SQL 查询来移动数据。

Answer 2

我建议只创建一个模型调用属性，并让每个需要许多的对象都有 has_many。然后你就不必搞乱序列化或任何类似的脆弱的事情。如果您使用 :join 语法，那么您不会遇到任何实际的性能问题。

将数据序列化到 RDBMS 中几乎总是不明智的。它不仅仅涉及查询，还涉及描述和迁移数据的能力（而序列化破坏了这种能力）。

class Building < ActiveRecord::Base
  has_many :attributes
end

class Attribute < ActiveRecord::Base
   belongs_to :building
end

create_table :attributes, :force => true do |t|
  t.integer :building_id
  t.string :att_name
  t.string :data
  t.timestamp
end

Answer 3

我面临着您所描述的同样的困境，并最终选择了键/值表实现，因为其他人提到的潜在的维护优势。与单个序列化哈希相比，在未来的迁移中，更容易思考如何选择和更新数据库的单独行中的信息。

我个人在使用序列化哈希时遇到的另一个问题是，您必须小心存储的序列化数据不能大于数据库文本字段可以容纳的数据。如果不小心，很容易导致数据丢失或损坏。例如，使用 SerializedProfile 类 &如果您描述的表，您可能会导致此行为：

profile = SerializedProfile.create(:settings=>{})
100.times{ |i| profile.settings[i] = "A value" }
profile.save!
profile.reload
profile.settings.class #=> Hash
profile.settings.size #=> 100

5000.times{ |i| profile.settings[i] = "A value" }
profile.save!
profile.reload
profile.settings.class #=> String
profile.settings.size #=> 65535

所有代码都说，请注意您的数据库限制，否则您的序列化数据将在下次检索时被剪裁，并且 ActiveRecord 将无法重新序列化它。

对于那些确实想使用序列化哈希的人来说，那就去吧！我认为它在某些情况下有可能发挥良好作用。我偶然发现了 activerecord-attribute-fakers 插件，它看起来很合适。