我目前正在构建一个Rails应用程序，其中有一个“文档”数据表，用于存储对生活在S3服务器上的pdfs的引用。这些文件可以有100种不同的类型。每种类型最多可包含20个属性或元信息。
我的困境是我是为每个doc类型制作100个关系表，还是仅使用对doc_id的引用创建一个键/值数据表。
我的直觉告诉我，随着时间的推移灵活搜索和支持越来越多的文档类型的关键/价值，而无需创建新的迁移。但是，我知道这种技术存在缺陷。我当然首先关心的是桌子的大小。键/值表最终可能有数百万行。
另一方面，在全文搜索情况下，拥有100个属性表将是一场噩梦。
因此，通过使用键/值，底线是3列Postgres表上的性能，可能有数百万行存在缩放问题？那么加入价值领域呢？
这种数据几乎不会改变。所以这将是90％的读数。
答案 0 :(得分：1)
考虑具有hstore列的单个表。它是一种PostgreSQL数据类型，用于存储键/值对。
http://www.postgresql.org/docs/9.1/static/hstore.html
还有多个Ruby gem为ActiveRecord添加了hstore支持。这是我写的一个：https://github.com/JackC/surus你也可以在ruby gems中搜索更多的替代品。