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>
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:
- You need to incorporate the comparison in the engine's infrastructure: sorts, indices, grouping, etc.
- 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)
- 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)
- 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