Re: database design method

From: Lauri Pietarinen <lauri.pietarinen_at_atbusiness.com>
Date: Sat, 16 Nov 2002 09:03:08 +0200
Message-ID: <3DD5EDAC.53F4D753_at_atbusiness.com>


> >Also Date's keynote address in this year's VLDB touches on the subject:
> >
> > http://www.cs.ust.hk/vldb2002/VLDB2002-proceedings/slides/S01P02slides.pdf
>
> Yes, but the object identifier as pointer is not the type of object
> identifer I (and the article I mentioned) was talking about.

OK, that's what I suspected.

> What I meant
> could also be called "abstract value" and is in some sense the theoretical
> clean version of surrogate identifiers. The big difference with surrogate
> identifiers is that the user can never get to see their value and the only
> operation that is defined for them is equality. Such a restricted type may
> seem a bit strange and not very useful at first sight but it makes the life
> of the DBMS easier (for example the DBMS can reuse identifiers that are no
> longer used) and allows the user to define views and queries in which new
> identifiers are generated without using some clever arithmetic to generate
> new surrogate identifiers. In fact, if such object identifiers are possible
> (including special operators to generate them) IMO the good old flat
> relational model would be all we need.

So is the function of these identifiers to act as an "internal glue"? Obviously they are not used as external identifiers because the "user" can't see them.

What is the problem with generating such values? If they are just integer values (say) and there is a process inside the engine that gives the system the next integer? Or maybe generates a random value within a large space and just quickly checks if it is reserved?

And one more question: what would be a practical query in which these abstract identifiers would be needed.

regards,
Lauri Pietarinen Received on Sat Nov 16 2002 - 08:03:08 CET

Original text of this message