1

I am currently building a Rails app where there is a "documents" data table that stores references to pdfs living on an S3 server. These documents could have 100 different types. Each type can have up to 20 attributes or meta info.

My dilemma is do I make 100 relational tables for every doc type or just create one key/value data table with a reference to the doc_id.

My gut tells me to go key/value for flexibility for searching and supporting more and more document types over time without having to create new migrations. However, I know there are pitfalls with this technique. My first concern of course is the size of the table. The key/value table could end up with millions of rows.

On the other hand, having 100 attribute tables would be nightmare to query against in a full text search situation.

So bottom line is, by going with key/value, is performance on a 3 column Postgres table with potentially millions of rows a scaling problem? Also what about joins on the value field?

This data would almost never change by the way. So it would be 90% reads.

4

1 回答 1

1

考虑一个带有 hstore 列的表。它是一种 PostgreSQL 数据类型,旨在存储键/值对。

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

还有多个 Ruby gem 将 hstore 支持添加到 ActiveRecord。这是我写的一个:https ://github.com/JackC/surus您还可以搜索 ruby​​ gems 以找到大约十几个替代品。

于 2012-07-11T02:51:37.223 回答