Re: A question for Mr. Celko

From: John Jacob <jingleheimerschmitt_at_hotmail.com>
Date: 3 Aug 2004 23:44:02 -0700
Message-ID: <72f08f6c.0408032244.73560e1a_at_posting.google.com>


Marshall,

Sorry, I've been away for a while.

> Can I ask what implementation you're referring to? Can you tell us
> anything about it?

I am referring to the Alphora Dataphor product. There is another thread regarding the possibility of implementing a truly relational database on top of existing systems in which I describe part of the SQL translation architecture. As far as the internal engine, the query processor runs execution plans which are trees of plan nodes, with each node representing an operator or flow control construct within the language. The arguments to each operator are child nodes of the operator node. For example:

x := 2 + 3;

becomes:

AssignmentNode
  StackReferenceNode
  AdditionNode
    ValueNode(2)
    ValueNode(3)

Execution proceeds from the bottom up, with each node responsible for evaluating its arguments, and performing the operation it represents. When the result type of a given node is relation-valued, the result internally is a cursor. This cursor is then used to range over the result set. Each relational operator is implemented by defining a different cursor type to implement the specific operation. For example, a SeekTable is used to implement a sargable restriction. In this way, the entire expression is pipelined, so that only as results are requested are they actually processed. For example, if I ask for all
orders in London, but I never actually step through the cursor, no work is performed. Of course, there are cases such as orders that require intermediate materialization, but we only perform these when required.

In addition to internal processing, the integration layer defines the same cursor-style interface, so that the result of processing a relational expression at any point in the tree can be performed by an external source rather than our engine. The SQL translation engine plugs in at this layer to provide the SQL equivalent of a given branch of the execution plan.

Now as far as non-scalar valued attributes are concerned, the D4 language supports them syntactically, but because our storage engine is actually existing systems, we don't provide any way to map those table definitions. We provide some simple devices for use in prototyping applications that would allow these types of definitions, but it's not an often used (or well tested) feature of the product. We have concentrated more on providing a solid platform for declarative application development using existing systems.

Regards,
Bryn Rhodes
Alphora Received on Wed Aug 04 2004 - 08:44:02 CEST

Original text of this message