Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Field Order via Oracle ODBC

Re: Field Order via Oracle ODBC

From: Vincent Quesnoit <Vincent.Quesnoit_at_bull.net.Earth.Solar_System.milky_way>
Date: Thu, 10 Jun 1999 09:02:15 +0200
Message-ID: <375F62F7.E7EBB45D@bull.net.Earth.Solar_System.milky_way>

Arvin Meyer wrote:

> 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
>

I found some instances when that kind of field (invoicelinenumber) is required as a complement to the detail primary key, that is when you need to record some order amongst detail records. I have a non-substantiated feeling that the autonumber primary key may not be the right field to do that. Once you do need that second level key, the Detail primary key looks redundant.

This design problem occured recently when I tried to break expressions such as : (a or b) and((b or c) and z) into a sequence of records to get a tabular representation. There you obviously need a key to designate an expression, and a key to order the elements within the expression. The big concern is : how do I let people change the content of an expression, and keep it in order. For me the answer was a LineNumber field. In that context the Autonumber key is redundant.

Vincent Quesnoit

> 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 Thu Jun 10 1999 - 02:02:15 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US