[lneves]

If your objects have a wide variety of attributes, either you need lots of columns with many of them empty, or you need some sort of attribute table with object-key-value triples. Both are bad relational design, but the structure is inherent in the data. If you're having to use a fixed DB schema, I can't see any way around bad design.

PostgreSQL HStore is very handy in situations such as this: http://www.postgresql.org/docs/8.3/static/hstore.html

[DannoHung]

So your solution is to point to a database capacity that violates the first normal form?

[fhars]

Um, no. "Set of key-value pairs" can be a perfectly valid atomic data type as far as the database is concerned, and so a database containing tables with hstore columns can be in any normal form you want, just like a database with varchar columns can be normalized, as long as you don't give the contents of the varchar or set any structural meaning as far as the database is concerned. There is nothing in the relational model that forbids storing composite values (even whole other database tables [edit: of which hstore is just a trivial example]) as a value of a field. Whether it violates any normal form doesn't depend on the type of the elements stored, but on their interpretation in your data model. Although that doesn't mean that I would be surprised if I saw a use of hstore that is ill-advised. Quite the opposite, actually.