Re: HTTP Frontend? (and a brief thought on materialized views)

On Wed, Apr 4, 2012 at 6:26 AM, Josh Berkus <josh(at)agliodbs(dot)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