Re: Hierarchy/Many to Many/Temporal data - MIND BENDER
Date: Mon, 18 Aug 2003 10:36:44 -0400
Message-ID: <3255958.1061217404_at_dbforums.com>
Originally posted by Me
> They are unique in the simplified example that I posted.
>
> In the future if there is a date in that table then you will be
> able to have
> the same skill assigned to the same experience twice. Each with a
> different
> date.
>
.. in which case I would add the date column to the primary key. That makes 3 columns in the primary key, so it does make a surrogate seem attractive for some purposes. You probably still want a UNIQUE constraint though.
Originally posted by Me
> With a surrogate key, the programming is easy:
>
> example asp script using surrogate key:
>
> I just use "select * from company where companiID = 45" in the
> above script.
>
> Or an application can pass a value to a form property in Access or VB.
>
> Example:
> myform.key=45
>
> What do you propose would be passed to the routine for editing
> the data
> after using multiple fields as a key?
>
Well, I don't use Access or VB much myself, so I may get this wrong, but what about:
myform.ExperienceID=11
myform.SkillID=22
Surrogate keys are fine in their place, but I don't really like the thought of the application tail wagging the database dog - it really should be possible to handle a composite key in the application, if a composite key is the logical choice for the table.
-- Posted via http://dbforums.comReceived on Mon Aug 18 2003 - 16:36:44 CEST