键/值Postgres SQL表性能

Question

我目前正在构建一个Rails应用程序，其中有一个“文档”数据表，用于存储对S3服务器上生活的pdf的引用。这些文件可能有100种不同的类型。每种类型最多可以有20个属性或元信息。

我的两难困境是，我是否为每种文档类型制作了100个关系表，或者只是通过引用doc_id创建一个键/值数据表。

我的直觉告诉我要找到灵活性的关键/价值，以便随着时间的推移搜索和支持越来越多的文档类型，而无需创建新的迁移。但是，我知道这种技术存在缺陷。我当然首先关心的是桌子的大小。键/值表可能以数百万行结束。

另一方面，拥有100个属性表将是全文搜索情况下查询的恶梦。

因此，最重要的是，通过使用键/值，在具有潜在数百万行的3列Postgres表上执行性能缩放问题？另外关于价值领域的加入呢？

这些数据几乎不会改变。所以这将是90％的读数。

Answer 1

考虑带有hstore列的单个表。这是一个PostgreSQL数据类型，用于存储键/值对。

http://www.postgresql.org/docs/9.1/static/hstore.html

也有多个Ruby宝石是添加hstore到ActiveRecord的支持。这里是我写的一个：https://github.com/JackC/surus你也可以搜索红宝石约十几个替代品。