Separation of Relational Engine from Domain Math

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- Received on Sun Apr 09 2006 - 09:10:31 CEST