Re: Proper relational database?

On Fri, Apr 22, 2016 at 2:05 AM, Guyren Howe <guyren(at)gmail(dot)com> wrote:
> If I had the time and money to put together a team to do this, I would start
> with the lower-level guts of either Postgres or SQLite (or, heck, MySQL) so
> you had a thing that did BTrees and other data structures on disk and
> indexes, and provide access to that from a high level, portable and
> efficient language. Perhaps Scheme.
>
> Then you could write a high-level relational logic engine on top of that, in
> the high level language, perhaps with the odd bit of C or D or Go for
> anything really critical.

Why is starting at a low level important? A database is truly
relational to the extent that it implements the relational model. If
you don't want the database to allow tables without keys, or to allow
null values, don't let people create them. If the underlying machinery
allows them, that seems like a mere performance issue; worrying about
that from the outset seems like a perfect example of premature
optimization. If PostgreSQL's performance is acceptable now, why
wouldn't it be acceptable with a different interface language?

There are other aspects of what would make a truly relational
database, of course. Codd's 0th rule, for instance, that the "system
must be able to manage data bases entirely through its relational
capabilities" to me says that there should be no data definition
language, except as syntactic sugar for relational operations. So
you'd create users (thousands in one command, if you liked) by adding
tuples to a base relation.

But which things are important? I think a good many of the things one
might would be lower-hanging fruit than that. Just having a clean
query language would alleviate a lot of (my) discomfort.

> I don't know if Postgres exposes the lower-level stuff to plugins or not —
> it would be nice if this could be an alternative query language for Postgres
> itself,

Well, the parser doesn't, but as best I can tell it's also somewhat
loosely coupled from the system. It doesn't do table access, for
instance. It builds and returns a parse tree. There's no reason you
couldn't parse a different language and return a tree of the same
type. Or you could just translate your input language into SQL, and
pass it along to the existing parser.

> but the assumptions about the two worlds (SQL vs a properly
> relational store) are probably too different.

Are there relational algebra expressions, or other operations
necessary to a truly relational database, which cannot be translated
into SQL? I'm not aware that there are, but I'd be interested to hear
of it. If there were, there's a good chance you wouldn't be able to
translate them into the parse tree, either.

--
Ray Brinzer