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

On Wed, Apr 4, 2012 at 9:53 AM, Dobes Vandermeer <dobesv(at)gmail(dot)com> wrote:
> 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.

Methinks this needs a *lot* more specific description of what you mean
by "document."

The thought that is occurring to me in this context is that the
"document" is simply an image (.png, .jpeg, .pdf) of a paper document
which might get associated with some of the 'business transactions' in
the database.

Thus, I'd be happy to be able to capture images of invoices, receipts,
and such, and associate them with the highly structured data for the
accounting transactions that they are associated with.

I'm not sure that this is the same thing that you are thinking of.  I
suspect that you might be thinking of a "document" as being a "loosely
structured set of data".  Though with the similarity that such
documents would get associated with the highly structured accounting
transaction data that they relate to.

It's not a ludicrously bad idea to have a series of supplementary data
tables that can get tied to transactions...

create table supplementary_bitmap (
 h_id serial primary key,
 created_on timestamptz not null default now(),
 metadata text not null,
 bitmap bytea
);
create table supplementary_xml (
 x_id serial primary key,
 created_on timestamptz not null default now(),
 metadata text not null,
 data xml
);
create table supplementary_hstore (
 hs_id serial primary key,
 created_on timestamptz not null default now(),
 metadata text not null,
 data hstore
);

And add some optional references to these to some of your tables.

That doesn't notably lend itself to doing a lot of work with the
relationships between bits of supplementary data.

There's not much that I *can* do if I'm attaching images of pictures I
took of invoices with my phone; there's not much about that that's
amenable to further automatic analysis.  It's still pretty useful, if
someone wants some proof that there was an invoice; I can produce a
copy that's tied to the transaction.  That's rather less than "OODBMS"
:-).
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"