Re: Is it possible to build a purely relational database on top of SQL?

jingleheimerschmitt_at_hotmail.com (John Jacob) wrote in message news:<72f08f6c.0407122316.29c30515_at_posting.google.com>...
>
> The short answer is yes, the long answer is no ;)

Hi John,

many thanks for your detailed reply and apologies for missing it until now.

> I am part of a software team that has built what I believe is as close
> to "truly" relational as is possible while still taking as much
> advantage of the performance and transaction management capabilities
> of existing systems as possible. It turns out to be a pretty tall
> order to combine the two, in fact, I believe, impossible without
> writing the system from scratch (or at least from a modified b-tree).

Welll... the Aditi deductive database project took that approach (roll-your-own, but traditional, RDBMS back-end with a deductive DB front-end) and found it hard to be competitive: check out http://www.cs.mu.oz.au/research/aditi
> Initially, the
> logical model was 100% pure, and (almost) 100% TTM compliant (if you
> would like, I can post a Manifesto Compliance document from the 1.0
> version of the product).

That would be very interesting.

> However, the design goals of the system
> called for translation into existing systems for performance.

Can you explain where you had to sacrifice relational purity? Presumably you weren't expecting your system to be retrofittable to existing DBs full of NULLs and all that other SQL nastiness.

> We knew
> we could not match, at least initially, existing systems in terms of
> sheer data processing power and query optimization (they've got thirty
> years on us in this department).

Have you any tech. reports or white papers or the like on your optimization technology and the problems you encountered interfacing with the back-end DBMSs?

> We initially supported type inheritance as
> well, but for various reasons we dropped it. One reason was the
> complexity of mapping a polymorphic operator invocation into a
> statically typed SQL-based system, as pointed out elsewhere in this
> thread.

I think you mean s/statically/non-polymorphically/?

> In creep nulls. The null semantics of existing systems are so
> ingrained that to completely avoid them, we would have had to support
> nothing but base table retrieval, leaving our query processor to do
> all the work.

This makes me think you *were* hoping customers could use your system on existing DBs containing NULLs. Or is the problem more fundamental than this - that is, you have to use NULLs to make even a non-backwards compatible system go fast?

As an aside, would the sky really fall if a database including NULLs was transformed into one using maybe-types (e.g. `NULL' ---> `no', non-NULL value `X' ---> `yes(X)')? I'm aware this may be a naive question, but since NULL has no declarative semantics that I can see, it looks to me as though any table containing NULLs can only be interpreted within the operational semantics of the query engine. Using maybe-types makes all that nonsense go away.

> While we spent a great deal of time making sure that the
> operations we did perform were done efficiently, the fact remains that
> Oracle and SQL Server will outperform us every time (at least today
> <evil grin>). In the end, we were forced to bow out and implement null
> semantics in exactly the same way that SQL-based systems do.

What was the performance penalty you observed?

> It is worth noting that not even this compromise is 100% correct. For
> example, Oracle systems do not distinguish between null and the empty
> string, most systems ignore trailing spaces when comparing character
> data, some systems consider rows with nulls less than rows without
> them for the purposes of sorting, other systems consider them greater,
> and the list goes on and on.

I always wondered what happened to my students who complained about all that "irrelevant theory stuff".

> If you would like more specific examples of the translation problems
> that forced us to the "null" conclusion, I would be happy to provide
> them. It's been a very instructive journey for us, and we plan on
> documenting the whole process once we have time.

Please do - I'm very curious.

Thanks again,
-- Ralph Received on Wed Jul 21 2004 - 06:54:18 CEST