Re: two nasty schemata, union types and surrogate keys

On Sep 26, 12:33 am, Sampo Syreeni <de..._at_iki.fi> wrote:
> Still, to return to my original point, what do y'all think about the
> encoding of facts such as "yes, there are two separate persons called
> John Smith, and no, we don't have any more information about them as
> persons, yet given their sets of cars owned, the one with a Ferrari
> and the one with a Lamborghini are two different persons"?
>
> I mean, normalization often calls for encoding the persons and their
> ownership of cars in two separate relations. The first of which
> seemingly cannot have a natural key. As such, a surrogate key would be
> required, and no real alternative would be possible.
>
> Personally I hate surrogates, though I use them for far less pressing
> purposes (i.e. performance). Still I think that's mostly because we
> don't really have the kind of true surrogates Codd suggested, where
> the actual, underlying value is completely hidden. Nor do we have a
> proper semantics -- Codd or not him -- for what a database with
> surrogates is supposed to mean, or how to make it safe from update
> anomalies and the like.
>
> The RDF data model is one rare example where we do have anonymous
> surrogates, in the form of "blank nodes". And we have a formal
> semantics as well. But otherwise, sadly, we're then once again into
> the quagmire that is EAV; or as I'd like to call it, gratuitous
> reification.

I think the surrogate key has no significance for semantics. If surrogate values are never displayed to database users, then even upon careful observation of the surrogates, I cannot notice an atom of semantics there.

Regarding “blank nodes” in the RDF data model, they merely indicate the existence of the thing, but not its name. But, a name is a really very important in semantics. A name is the glue that binds a thing in our mind to the corresponding thing in the real world. In the further development of computers, probably in a future semantic machine, solutions like surrogate keys have no relevance.

Vladimir Odrljin Received on Mon Oct 26 2009 - 11:11:04 CET