At 03:21 PM 8/12/2003 +0800, you wrote:

>Thank you Helen. Not for only solving the problem. But also on guiding
>me on some design. I more question. Back in my schools days, my teacher
>or professor didn't tell us that a detail table has to have a primary
>key, but only a foriegn key. The right one is even a detail table has to
>have a primary key?

For sure. A detail table is not special - it is a table like any other. A
foreign key *by nature* is not supported by a unique key, except when you
have a 1:1 relationship between the dependent table and the master table.

From the perspective of extreme old age, I want to tell you that a dynamic
table without a primary key is about as useful as a bicycle without
wheels. What teachers try to teach very in colleges often has no validity
in real-life systems - mostly, I suspect, because the professors have never
got their hands dirty in any factory where IT systems get designed. It
amazes me how many IT graduates I discover who have never heard the term
"atomic" when used in the context of database design. Yet atomicity is at
the very heart of a good, robust database design. If the professors aren't
teaching you the basic principles, they don't deserve their jobs.

Helen