Craig Ringer wrote:
On 20/10/10 13:12, Darren Duncan wrote:
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.
You can for trees/forests yes. How would you handle more general graphs
with cycles or bidirectional relationships, where you still want to be
able to reconstruct them into a traversible graph client-side?
There are existing graph databases for this, of course, but I've
frequently wished to be able to use the power of SQL's query language
and reporting facilities with my data as well as being able to extract
it as (sub)graphs when needed. Using a graph database would usually cost
me ACID, full SQL support, and in most cases all those goodies like
triggers, constraints, etc as well.
I think there's a real use case for using regular relational storage
with a few SQL extensions to support returning graph-style rather than
row-set style results. Even the SQL extensions probably aren't necesary;
I suspect a (limited and somewhat slow) version could be done purely in
a PL under PostgreSQL, and I've been thinking about trying to prototype one.
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
You'd really wow people if you could bang together a working JPA 2.0
backend for that, or a dialect for an existing provider like Hibernate.
Personally, I'd love to give someting like your Muldis-D query interface
a go if it could live within PostgreSQL as a contrib module, using the
regular Pg storage and just providing an alternative query facility.
Right now, it looks like it is a perl-all-the-way system, with no
interfaces for other languages and its own database storage system. In
its current form a quick glance at the docs doesn't demonstrate any
obvious advantage of using it over any of the existing well-established
graph databases or object-relational database systems.
Muldis D is a work-in-progress. The system is specified in terms of a
programming language of which multiple implementations could exist, essentially
the same way as SQL is. I fully intend for it to run on Postgres, using regular
Pg storage (which may gain features along the way), and be useable both in the
manner of a PL and for general DDL/DML/queries/etc. I agree that it is best for
the initial all-in attempt to be done as a contrib module, and I am happy that
Pg already has so much of the infrastructure in place that is needed. The
first, Perl-all-the-way, system is just the reference implementation, but the
Pg-contrib version would likely be the first one for serious use.
If you or anyone wants to work on making this a reality, I welcome it.
-- Darren Duncan
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
