Hacker News Reader

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.

When you mention object databases, can you name any examples? As far as I know object databases where talked about a lot some years ago, but never really gained significant widespread adoption.

Also, the article makes the point that non-relational databases are not just about scalability. In fact, in the case of graph databases, scaling problems are just as pronounced as with relational databases. The different data models can enable you to make good database designs, even if the structure of your data is against you.

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

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

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.

I've been playing with the db4o OODBMS. So far my tests are simple and I've been using tinker toy Scala programs to test against it, but I love the simplicity. I could definitely make a case for using it in an OLTP department-sized application. Beyond that level, I haven't tested enough to be comfortable giving advice either way.

Pretty interesting. I never heard of db4o before. I'm skimming the tutorial (http://www.db4o.com/about/productinformation/resources/db4o-...), and it looks fairly nice.

It seems that db4o supports some pretty flexible query mechanisms. That leads me to worry about performance. One of my recurring nightmares of relational databases and SQL is optimizing queries on non-trivial constantly-evolving schemas, and I can't help wondering if db4o has the same horrors in store.

Unfortunately my tests have been too basic to give any advice in your situation. Adding data elements has been nothing more complex than adding it to the class. Queries that filter on elements in a single class are trivially easy - but I think there are types of applications that need nothing more. Querying across classes would require more work than the relational equivalent of querying across multiple tables.

HOWEVER, my sense is that bringing a relational mindset to object databases is not going to realize the full potential of them; you have to think about storing the data elements differently.

Object databases seem great for OLTP apps. In particular, ones that require working with individual accounts/patient charts/etc, i.e. query a person's account, modify a data element, and save it back to the db. For something more analytical, like spotting trends in historical data, I'd prefer the full power of an RDBMS and the SQL language that goes with it.

"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...

Frequently you can avoid having object that have a wide variety of attributes most of which are empty in the first place. That often indicates that the objects are not of the same type and that that table should be broken into other tables of objects that are truly alike.

That, though, is not always the case. When you truly have that situation with objects of the same kind, then I do not see why allowing the numerous empty columns (as long as they are all bound to the key and only the key) or the "object-key-valuy" tables are bad relational designs. If I am missing something, please let me know.

As for the object databases, the only one I have really heard of is db4o as another posted mentioned. I do believe that they are used in some areas of physics though. I have never used them personally, but I have heard of people using them in small scale projects just as a way to avoid the object-relational impedence mismatch complications.

To your last paragraph, I agree completely. There is room and a place for both relational and non-relational databases.

(or that the problem you were trying to solve changed along the way)

All non-trivial problems change along the way.

> not to say that the relational model is right for everything. In some cases, object oriented databases are the way to go

Allow me to channel CJ Date and point out current popular databases are not truly relational. A proper relational database built around Tutorial D would pretty much always be the way to go, even if your problem is highly OO.