Re: [SQLObject] Re: SQLObject

[Brad B. <br...@bb...>]

On 04/11/03 15:08, Bud P. Bruegger wrote:
> On Fri, 11 Apr 2003 07:58:45 -0500
> Brad Bollenbach <br...@bb...> wrote:
> 
> > There's no implication in there that they do carry business
> > meaning. I.e. project_id and worker_id could easily be integers (and
> > each table could later have a name column, e.g. project_name,
> > worker_name, etc.)
> 
> Hmmm.  you're right!
> 
> But assume there are other tables referencing ProjectWorker; say
> ProjectWorkerComment.  Assume, they also use composite keys:
> 
> project_id 
> worker_id 
> comment_id 
> 
> (where (project_id, worker_id) is a foreign key referencing
> ProjectWorker
> 
> Then, if you reassign the project to another worker, you also have to
> change the composite key of the related comments.  
> 
> So you could say that the business meaning is not in the key itself
> but in the relationships you define in terms of the keys...

Hmmmm, I don't see the problem here. You have two options when
assigning a different worker to the project:

1. A simple update on worker_id, in which case all previous comments
in your comments table will now look like they refer to that new
worker_id (which may or may not be what you want).

2. Inserting a new row into ProjectWorker, which provides separation
between the comments related to each worker who's done work on the
project.

In either case, this will not affect anything in comments, because
this is a table that would probably look like:

Comments
comment_id
comment_desc
...
etc.

It doesn't care what kind of update-fu you do on the composite key of
ProjectWorker (and ProjectWorker probably doesn't care either, unless
-- of course -- the update tries to duplicate an existing
project/worker pair).

-- 
Brad Bollenbach
BBnet.ca