On Sun, 31 Jan 2016 18:15:48 -0500 "James K. Lowden" <jklowden at schemamania.org> wrote:
> > The relational model, as you well know, doesn't describe > implementation. It's math. It says what relations are, and how > they're manipulated. One data type, and an algebra closed over that > domain. Math doesn't have pointers or duplication or corruption; those > are computer concepts, and as such are entirely outside the model. I feel better to read this, as I had a doubt on the assertion. There is even another way to comment, bringing pointer interpretation into the model: an identity, which is fine in a relation model, is a value of some type, to which equality applies; a pointer is an identity, although an identity is not always a pointer, as a pointer is additionally a kind of array index which implicitly implies a relation to one. So ?pointing to? is a reasonable interpretation of some relations, when it reads from many to one (which may be for both ways, one way only, or not at all). An identity may still sometimes be interpreted as a pointer, with only the dereferencing method differing: either relation or array index. That said, I tried to have some meditations on whether or not I should use ID in place of values or not, while testing it in practice. Here is how I see it (to not say all)?? identities and general values, are not the same things, as while same identity implies same value, same value does not always implies same identity. The latter, to be assumed, needs to be asserted. There are also representations. Sometimes there is not really a value, just an identity which is the only thing offering sense/meaning, and what may be erroneously seen as a value is rather a representation. For the latter case, this is better to deal with the identity rather than with the representation interpreted as a ?value?, because the representation may vary, so it's cleaner to use the identity rather than the ?value?, to make senses. To come back to values, when the only thing which locally matters with a value is equality, it is valid to locally assert the value is the identity; this may be handy with composite values (save complexity folding a complex value) or often repeated values (*may* save storage). But this comes with an issue, at least one SQL construct prevents from referring to the value corresponding to an identity (when not just equality is needed): within indexes. Ex. table T has column "a" (an ID) and "b" (an associated value), table U has a column "c", where "c" references column "a" from T, then there is no (or I know no) way to create an index on U(c) ordered by the associated value "b" from T. That's abstract, but the practical result is there: the request grouping on what was a second column, is now *exactly* as fast as the request grouping on what was the first column (there is no more technical differences between the two queries), and the DB size is two third of its size before this refactoring. All of this, using ID in place of *some* values???however at the cost of more verbose queries (more verbose, but not untraceable, this is just tedious). -- Yannick Duch?ne
