Re: Hierarchy/Many to Many/Temporal data - MIND BENDER

From: andrewst <member14183_at_dbforums.com>
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:

> exp.asp?action=edit&key=45

>

> 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.com
Received on Mon Aug 18 2003 - 16:36:44 CEST

Original text of this message