Re: Proper relational database?

> 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?

Agreed.

> 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.

Yes, maybe, but that makes it not part of the language. You can't apply rule 0 to things like creating a type or operator in a language.

> 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.

Andl is that.

> > 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.

I looked into that, and it's too hard as a starting place. There is too much of the tree and the subsequent query planning that is hooked into specific features of SQL. Instead, Andl generates a small subset of SQL. Once each query has been generated and parsed, the prepared statements can be cached and you get most of the benefits.

> > 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.

Absolutely not. SQL is a (nearly) full implementation of the relational algebra, plus other non-relational stuff. The only thing it really can't handle is a table with no columns! (I have to fake that)

Regards
David M Bennett FACS

Andl - A New Database Language - andl.org