Re: Field Order via Oracle ODBC

Disagree! There are many detail records for a given Invoice Number. The only thing which distinguishes them, from a logical viewpoint, is, the fact that they appear on different lines of the invoice. They are thus distinguished (for that Invoice) by a notional Invoice Line Number. You can certainly allocate a unique number (across all detail records) for each detail record, but that's a physical design decision - not a logical data modelling issue. From the logical data modelling viewpoint, I still contend that the primary key of the detail table is Invoice Number + Invoice Line Number.

TC
(No email)

Arvin Meyer <a_at_m.com> wrote in article <7jm5io$tub$1_at_esinet2.esinet.net>...
> No, that is not they way it is handled in a normalized databased.
>
> Invoice Header -primary key = InvoiceNumber
>
> Invoice Detail - primary key = InvoiceDetailNumber
> foreign key = InvoiceNumber
>
> InvoiceLineNumber is extraneous and doesn't even need to be recorded,
merely
> displayed for the convenience of the viewer. Composite keys should be
> avoided if possible in detail records, unless they are used in a join
table
> in a many-to-many relationship.
> ---
> Arvin Meyer
> onsite_at_esinet.net
>
> TC wrote in message <01beb294$fa0e55e0$53fa98cb_at_pentium>...
> >
> >Brad Pybus <brad_pybus_nospam_at_hotmail.com> wrote in article
> ><%%v73.1733$sk1.2500_at_client.news.psi.net>...
> >> We never use multi-field primary keys.
> >
> >
> >But how can you avoid so doing?
> >
> >In any master/detail relationship, the detail record will normally need
a
> >composite primary key, namely:
> >* the master key of the parent table, plus
> >* the extra field which distinguishes the child records for a given
master.
> >
> >For example:
> >* Invoice Header -primary key = InvoiceNumber;
> >* Invoice Detail - primary key = (InvoiceNumber, InvoiceLineNumber).
> >
> >Yes? No?
> >
> >TC
> >(No email)
Received on Fri Jun 11 1999 - 08:00:58 CDT