Re: does a table always need a PK?

In message <bi6jr1$5gtvg$3_at_ID-125932.news.uni-berlin.de>, Christopher Browne <cbbrowne_at_acm.org> writes

>In the case of your BOOK relation, it might make sense for the
>relation to look something like:
>
>create table book (
> isbn isbn,
> page integer
> primary key (isbn, page)
>);
>
>(Where the ISBN domain is one that characterizes ISBN ids. You might
>alternatively use an internal identifier, and have the ISBN in a "book
>catalogue" table...)

To be pedantic (and I am replying to this in a theory newsgroup) you should probably call this table Editions instead of Book. If you have two books with the same ISBN they are instances of an edition. You would expect two books with the same ISBN to have identical pagination.

If you want to distinguish between books which are copies of the same edition you may have to introduce some other distinction.

Two that actually exist are the "state" and "printing."

If an edition of a book is printed and half the copies are bound in yellow covers and half have green covers then whichever went on sale first is the "first state." This can have make a factor of 10 difference in their selling price.

Typically popular books are reprinted and these days the number of the printing is recorded on the flyleaf. Successive printings may have the same ISBN but collectors always want the first printing. The difference in price between a first printing and a later one may be $30,000 so this is something that a collectors' or sellers' database must record.

-- 
Bernard Peek
London, UK. DBA, Manager, Trainer & Author. Will work for money.