Fons,
> Well, I started with "I'm a beginner". But I'm sure there's no reason
> NOT to
> accept two records that are exactly the same. In the example I gave,
> it is clear
> that the information I want to store can contain two records that are
> exactly
> the same; doing the same thing, on the same day, for the same amount
> of time. In
> this case it is the technical structure that doesn't want it like
> that. So I
> have to change it to make it work.
Yes, there is a reason not to accept them. And the requirement is
conceptual, not technical -- that is, the way relational databases work
-- *all* relational databases -- is founded on 12 concepts, one of which
is the uniqueness of relations (records).
Or, to phrase it another way, if your design allows identical records
(person, task, time period) then how are *you* going to seperate
illegitimate duplicate data-entry from legitimate identical records?
You can't, and the questionable accuracy of your tables will haunt you
for years.
I'm trying to save you months of pain & suffering here by conveying a
very important concept in database design, one I learned the hard way.
For a more exhaustive explanation of the necessity of uniqueness and
primary keys, please pick up a copy of Fabian Pascal's "Practical Issues
in Database Design."
-Josh
______AGLIO DATABASE SOLUTIONS___________________________
Josh Berkus
Complete information technology [EMAIL PROTECTED]
and data management solutions (415) 565-7293
for law firms, small businesses fax 621-2533
and non-profit organizations. San Francisco
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
