Re: Database INNOVATION

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