Re: Indexes and Logical design

"VC" <boston103_at_hotmail.com> wrote in message news:GKqdnRE4MfQ4gb7eRVn-sQ_at_comcast.com...
>
> "David Cressey" <david.cressey_at_earthlink.net> wrote in message
> >If we're going to take away the pointers they love
> > to play with, we'd better throw them a bone. Indexes fill that bill.
> >
>
> I do not understand the above. Are you talking about some psycological
> problems that can be settled if the hypothetical, non-database,
programmer
> would know tha some table has indexes ?

It has to do with the real world. Nothing that needs to concern you, VC.

> You are right of course that constraints are part of the logical model.
> However, the unique index is not. Such index is just an implementation
> vehicle for a unique constraint. Besides, in Oracle (with which you are
> apparently familiar) , a unique constraint can be enforced via a
non-unique
> index. This piece of trivia should make it clear that an index, either
> unique or non-unique, is just a trick to improve performance. One can
> easily imagine a unique constraint enforcement without any index
whatsoever
> although such enforcement would be impractical.

Not true. In DEC Rdb/VMS a unique constraint can be declared without creating an index, if you want to.
There are actually cases, though rare, where that's the right thing to do.

>
> >
> > Fourth, the DEC Rdb/VMS command "show table" shows the indexes as
part
> > of
> > its display.
>
> Surely, you realize that it's just an impementation pecularity, a
> convenient tool for the DBA.

Life is full of "implementation peculiarities". So far you've dismissed Oracle, Rdb, and Data Architect
peculiarities as unimportant. What's left?

> Well, as a database designer, you convert your conceptual simplification
> of the 'real world' into a logical model and then you think how to
implement
> this model using various tools at your disposal (indexes being one of
> them). Such impementation would be your physical model.
>

Nope. There is more than one logical model that corresponds to the same conceptual model. You make choices based on the probable consequences downstream, after implementation. Some of this is hunch work, and not strictly mechanical.

Again, it's from the real world. Received on Sat Sep 10 2005 - 22:36:05 CEST