Re: does a table always need a PK?

etp wrote:
>
> If I want to model say a book where I have a root element of book
> represented as n pages, can I do something like this:
>
> table BOOK
> -----------------------------
> pageid FK
>
> and
>
> table PAGES
> -----------------------------
> pageid PK
> content text
>
> i.e do I need to have a (f.e.) primary key in the BOOK table?

That's the wrong question. You should first ask if you really need the BOOK table. Since it is always going to be a projection of the PAGES table on pageid it doesn't really add any information that is not already in the PAGES table.

> The only
> reason I can see that I would want to is if I want to have many different
> books but then I would have to have BOOK, and then a BOOK_PAGES joining
> table no?

No. All you would need is a FK in PAGES that points to the PK of BOOK and indicates to which book the page in question belongs.

> Danke!

Bitte.

• Jan Hidders

PS. Homework: Explain the relationship between Wittgensteins famous last

    proposition (#7) in the Tractatus Logico Philosophicus and the     requirement that every table should have at least one candidate key. Received on Sat Aug 23 2003 - 00:49:22 CEST