Re: Stupid Database Tricks

From: David BL <davidbl_at_iinet.net.au>
Date: Mon, 11 Jun 2007 19:14:05 -0700
Message-ID: <1181614445.531555.185050_at_d30g2000prg.googlegroups.com>


On Jun 12, 12:13 am, Marshall <marshall.spi..._at_gmail.com> wrote:
> On Jun 11, 1:40 am, "Brian Selzer" <b..._at_selzer-software.com> wrote:
> > "Keith H Duggar" <dug..._at_alum.mit.edu> wrote in >

> > > There is no such "object" as an "object". If you stop thinking
> > > in terms of "objects" and "entities" then you will stop having
> > > the fake problems which lure you to the surrogate ID crutch.
>
> > I would have to stop thinking altogether: without objects there can be no
> > conception; without objects there can be no perception; without objects
> > there can be no discourse!
>
> Well, that seems a bit overstated. I think abstract algebra shows
> us that it's possible to work usefully with a formal system even
> without having a specific model in mind.

I've never come across any mathematical system that doesn't have "things". This is irrespective of the fact that the axiomatic approach often states properties about a set of things without uniquely defining them.

There are good reasons to avoid surrogate IDs. I'm coming to think it has little to do with how one conceptualises in terms of entities, and has more to do with the idea that a relation should preferably have a simple, sensible and stable intensional definition from which its extension can be uniquely determined (and could depend on time) through knowledge external to the database.

intensional definition: S1 = The names of the studio albums of the Gorillaz
extensional definition: S2 = { "Gorillaz", "Demon Days" }

The introduction of surrogate IDs for the studio albums is incompatible with extensions that are uniquely determined from simple intensional definitions. It has *nothing* to do with whether one conceptualises in terms of studio albums as entities.

That being said there seem to be cases where surrogate IDs are inevitable. Eg an electronic circuit needs every node to be uniquely identified. Received on Tue Jun 12 2007 - 04:14:05 CEST

Original text of this message