On Wed, Apr 4, 2012 at 6:26 AM, Josh Berkus
<josh@agliodbs.com> wrote:
> While I was doing this I always thought this would have been a better
> approach for my previous project, an accounting application. If I could
> just have stored entities like invoice & customer as a single document that
> is inserted, updated, etc. atomically it would be a lot simpler and faster
> than having to break things out into columns and rows spread over various
> tables.
Actually, an accounting application is the *worst* candidate for
document-oriented storage.
I guess I didn't go enough into detail. As it's a small business bookkeeping system the records are added after the fact. Constraint checking isn't a priority; we would allow someone to enter sales before purchases and things like that which means the constraint checking has to be more about flagging issues (we didn't get around to that yet, either). It wasn't an ERP and didn't support inventory so there's no worry about searching for inventory counts in particular locations. The idea is to input source documents like invoices & receipts and generate reports for stakeholders.
I think there is something to be gained by having a first-class concept of a "document" in the database. It might save some trouble managing parent/child relations, versioning, things like that.
I hand-craft some materialized views back then, too, since the conversion from a document (like an invoice) to the actual impact of that on account ledgers and balances was non-trivial and evolving as the feature set expanded, so it wasn't something you wanted to try and build into your reporting queries.
Yes, having "documents" *in addition* to relational data gives you the
best of both worlds. You can use relational structures to store data
which is well-defined and business-critical, and document structures to
store data which is undefined and not critical.
Well that's exactly what I was trying to get at in the first place :-). I'd love to see this kind of functionality in PostgreSQL and I think materialized views are a pretty powerful way to do that when you are automatically pulling fields out of the document to make the relational tables.
> So I kind of think the document database kind of bridges the gap between an
> OODBMS and the RDBMS because the document is like a little cluster of
OODBMS != DocumentDB
Yes, I know. I was just saying that a document DB is a bit more OO because the document itself is stored as an object graph rather than just tuples. Thus it fits in between RDBMS and OODBMS in a way. It makes sense in my head somehow, no need to agree with me on this one.
Regards,
Dobes
