Re: Nested Relations / RVAs / NFNF

>> The key is a set of attributes, not the value of those attributes.
The
>> "key-ness" of an individual attribute (its membership in one or more
of
>> the candidate keys) is orthogonal to its type.
>
> Sure. And that makes perfect sense for natural keys. But datatypes
> as such should support the appropriate operations-- no less, and
> no more, either. It doesn't make sense to have division on strings,
> eh? When we need a surrogate key, what are the desired
characteristics
> we want for that datatype? It ain't addition.

Ah, I did misunderstand your point, sorry. Agreed that integer shouldn't be used unless you plan on doing integer operations, and similarly with string operations.

> I'm trying to figure out
> what are the minimum characteristics for such a datatype, and
> as best I can figure, all we need are 1) create 2) test equal 3)
copy,
> which actually strikes me as three things that every datatype
> *must* do.

1. Creation requires a parameter, unless you have a single value or a generator. Otherwise, such as with an Oracle sequence, you've got a service doling out the "next" value. Are you talking specifically about generating a new, unique value?
2. Equals, definitely. I don't think it's controversial, but I think there might be problems with letting the system implement it for all user-defined types.
3. Why copy?

> Hmmm. Okay, I guess now I see what you mean about the orthogonality
> of keyness and type. Still, I'm starting to see a semantic
distinction between
> natural and surrogate keys

Perhaps. Then again, maybe not; if I use Social Security number, a natural key for U.S. citizens, it has the same semantics as a surrogate key. Then I suppose it's a natural surrogate key... or is that a surrogate natural key? :-)

A twisty question this raises is: for what subset of things we typically regard as String are string operators actually ever used? And then in a language like Java, how would you cope with this almost-a-string-ness?

• erk