Re: Surrogate Keys As Part Of Composite Keys?

<markp7832_at_my-deja.com> wrote in message news:8bljqi$m1a$1_at_nnrp1.deja.com...
> In article <mPoD4.24171$6b1.437249_at_news1.online.no>,
> "Thomas Muller" <ttm_at_nextra.com> wrote:
> > The general rule is that for 1-n relationships from A to B, B has a
 primary
> > key excluding the reference to A. In a n-m relationship, a new table
> > including only the composite key as added "between" the original
 tables.
> >
> > --
> >
> > Thomas
> >
> I am not sure what Thomas is trying to say, but if you have a parent to
> child relationship from A to B, let us say like, order header to order
> line items, it is normal to carry the Key of A, the order number, to B
> so that order number and line number would be the unqiue key of B. The
> is no need to create a seperate primary key to B because when will you
> ever use it? You will be accessing B based either on all lines for the
> order number in A or by a specific order number, line item number
> combination.
>

Thanks, Mark. My reply was a little too hasty, I meant that if B had a unique key (like an employee) the primary key should not include a reference to other tables, such as e.g. department. The order/orderline is an excellent example of a parent/child relationship where the child has only one candidate key which includes the reference to the parent.

--

Thomas