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