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

Question

如果我有几个对象，每个对象基本上都有一个Profile，我正在使用什么来存储随机属性，那么它们的优缺点是什么：

1. 将序列化的散列存储在列中以进行记录，而不是
2. 存储一堆belong_to主要对象的键/值对象。

代码

假设您有类似以下的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％的时间不需要按自定义进行搜索settings。只是想知道在性能和未来问题的可能性方面要进行哪些权衡。自定义的数量settings可能会在10到50之间。

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

注意：我只想知道RDBMS。这将非常适合MongoDB / Redis / CouchDB / etc。但我只想了解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）。带有activerecord-postgres-hstore gem的Rails
3用户也可以使用Hstore。

我正在将项目中的一些非关键首选项表迁移到hstore。在迁移中，我只更新表定义和execute每个表一个SQL查询以移动数据。