views:

437

answers:

1

The Java JCR API defines a persistence mechanism which can be used to replace many of the traditional roles of a RDBMS. For example, JackRabbit - the JCR reference implementation - supports transactions, SQL queries, object-content mapping, etc.

You could pick one or the other, storing binary data in BLOBs/file system pointers in a RDBMS or textual data in JCR node properties. Does anyone have experience replacing tossing their DB in favor of JCR?

You could use both, perhaps storing binary data in the CR and textual data in the RDBMS, but then you have to express relationships between systems, keep them in sync, etc. You also begin facing the difficult question of, "Well it feels right to store this document title with the document's binary data, so I'll make it a node property... but then I have this document record in my DB so perhaps I should keep it there.."

How do you decide?

+4  A: 

There is a paper by Bertil Chapuis on exactly that topic:

JCR or RDBMS?

And there is also the NoSQL movement (described in this article for example, or here), which is an ongoing discussion that, hmmm, let's say, "highlights" the disadvantages of the relational model.

Alexander Klimetschek

related questions