Separation of Relational Engine from Domain Math

This is based on a question I raised on c2.com:

The issue of seperation of relational from the "domain expression
engine" recently came up in a debate where the somebody claimed that
finding the nearest N points to a given point in a geographic map
system would have to traverse every point under relational, and thus be
O(n). A solution is to move such operations to the domain language
instead of let the query language directly do it. Example based on
basterdized SQL:

...WHERE pointID IN nearest(myTargetID, 10) // nearest 10 points

This way, one does not have to entirely abandon relational to get
decent performance for certain kinds of operations. A domain-specific
operation/function, "nearest", is introduced into the expression
language here. Standard SQL may not allow such, but SQL is not the
pinnical of relational and seems to dismiss the concept of separation
of domain math from relational math.

I have not seen much info about how and whether the "expression engine"
can or should be considered orthogonal to the "relational engine", as
long as a minimum set of requirements are met. It seems the relational
engine only needs a way to know how to interpret expressions into
Boolean values. Thus, any math that can produce or be interpreted as
Boolean can be "inserted" into the relational domain. Beyond that, the
sky is the limit. What the "cell types" are is also up to the domain.

Does anyone know of Dr. Codd or C. J. Date work on such separation?

-T-

.

Relevant Pages

  • Re: SQL
    ... SQL is more or less based on "COBOL thinking". ... possible nor most type-free that a relational query language can be. ... What makes up the expression engine is ... quotes or not in context typing. ...
    (comp.object)
  • Re: SQL
    ... The "expression engine" can be logically seperated from a relational ... query language, in theory they could without busting relational. ... They all are typed, as well as SQL. ... everything as pretty much a string. ...
    (comp.object)
  • Re: SQL
    ... SQL lacks a lot of stuff. ... I see nothing that keeps an RDBMs engine from using such techniques to ... A custom engine does ...
    (comp.object)
  • Re: SQL
    ... to have an ability to place things into cells ... It is a language issue then. ... An RDBMS engine that may ... Put a program code in a relational table and write compiler in SQL ...
    (comp.object)
  • Re: SQL
    ... SQL lacks a lot of stuff. ... Same with relational languages. ... I see nothing that keeps an RDBMs engine from using such techniques to ... A custom made/tuned relational engine is certainly as possible ...
    (comp.object)
Loading