From: | Darren Duncan <darren(at)darrenduncan(dot)net> |
---|---|
To: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Database INNOVATION |
Date: | 2010-10-20 05:12:36 |
Message-ID: | 4CBE7A44.505@darrenduncan.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Craig Ringer wrote:
> Now, personally, if we're talking "database innovation" what I'd like to
> see is a built-in way to get query results straight from the database as
> graphs of tuples and their relationships. Tabular result sets are poorly
> suited to some kinds of workloads, including a few increasingly common
> ones like document-oriented storage and use via ORMs. In particular, the
> way ORMs tend to do multiple LEFT OUTER JOINs and deduplicate the
> results or do multiple queries and post-process to form a graph is
> wasteful and slow. If Pg had a way to output an object graph (or at
> least tree) natively as, say, JSON, that'd be a marvellous option for
> some kinds of workloads, and might help the NoSQL folks from whining
> quite so much as well ;-)
Never mind JSON. You can fix the outer joins problem and other issues simply by
supporting relation-valued attributes, or in other words, row field values that
are rowsets. And recursively. Parent records in outer rowset, child records
inside. And this is all perfectly normal for the relational model, and SQL's
differing from this is part of how SQL is crippled and not really the relational
model. I demonstrate how it might be better done with my Muldis D language. --
Darren Duncan
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2010-10-20 05:12:43 | Re: Database INNOVATION |
Previous Message | Brent Wood | 2010-10-20 04:35:44 | Re: Database INNOVATION |