|
![](/i/fill.gif) |
Nicolas Alvarez wrote:
> From a *practical* point of view... Should that link table refer to tasks by
> their names?
It should refer to the task table by its primary key. Assuming users adding
tasks are required to pick unique (and hopefully meaningful) names, that
would be a good primary key. If there's nothing else actually unique about
the job, then a uniqueID field is about as well as you can do. But you can
almost always find something unique, like timestamp+submitter.
Now, if you're going to start mucking up your relational model because it's
too slow, first ask yourself if it's actually too slow. :-) Alternately, add
a *second* unique key, and put that in both tables, just for efficiency.
> It's a known unique property, and I can "digitize" it.
By "digitize", I meant stuff like each customer is actually unique, but what
makes that customer unique is not something that's easy to get into the
database. Every attribute of an actual customer that's easy to put into a
database is also something that a customer might change some day. Phone
number? Obviously not. Name? Hope they don't get married. Etc. Tax number?
Hope they don't change citizenship. Etc.
--
Darren New, San Diego CA, USA (PST)
The question in today's corporate environment is not
so much "what color is your parachute?" as it is
"what color is your nose?"
Post a reply to this message
|
![](/i/fill.gif) |