Re: The naive test for equality

From: DBMS_Plumber <paul_geoffrey_brown_at_yahoo.com>
Date: 31 Jul 2005 14:58:57 -0700
Message-ID: <1122847137.142084.67550_at_g44g2000cwa.googlegroups.com>


You define equality either a) by declaring an equal() relation and populating it with equality mappings (no one does this), or else b) by incorporating into the engine a module of non-declarative code which returns 'true' or 'false'.

For consistency, you might try adding a module 'compare()', instead of 'equal()', because that will get you the set of comparison operators to boot. Most Object-Relational DBMS products adopt this practice.

Numerous other practical problems arise:

  1. You need to incorporate the comparison in the engine's infrastructure: sorts, indices, grouping, etc.
  2. For some sort algorithms (radix) and other physical operations (hash joins, bloom filters, mapping tuples to partitioning schemes) the bit-wise representation of the value needs to be consistent with the logical operations (or you need to write code to convert your representation to something that's bit-wise consistent)
  3. Nothing on the whole green earth can help you if you decide to change the definition of these functions in an operational system, or try to do a database restore with different functions. You have to unload the DBMS, and re-load it again, or else engage in huge amounts of conversion jiggery pokery (this factor heavily influences the design of type extensions)
  4. Support for distributed computing needs care, because of byte-orderings, etc.

All of these trade-offs and questions were thoroughly explored in the systems research literature a decade ago. Most SQL DBMS products provide the functionality to some degree. Received on Sun Jul 31 2005 - 23:58:57 CEST

Original text of this message