Re: OT: updating database question

Maybe this wouldn't be absolutely necessary, but it might save you some effort if you add an auto-increment row-ID field on the "people_who_have_qualifications" table. That way, when a user asks to see all the qualifications for Alice and might decide to make changes, you get a set of distinct row-ID handles for the records that currently exist as you provide these rows for review.

The user can then select one or more particular rows for update or deletion, and you can do the specified update or deletion directly on the selected rows, using the row-ID that you've kept track of in the UI. (The user doesn't need to see the row-ID -- you just need to keep track of it.)

Comment on Re: OT: updating database question

Replies are listed 'Best First'.
Re^2: OT: updating database question by herveus (Prior) on Jul 23, 2007 at 11:51 UTC
Howdy! Ack! Surrogate keys gone wild! Seriously. My first thought is to wonder why the main tables use surrogate keys at all. In any case, adding a surrogate key to the third table doesn't necessarily add value. If you want, say, to see all the qualifications Alice holds, you simply constrain the query to get them. The combination of name and qualification uniquely identifies the row already -- no surrogate key needed, along with its care and feeding. yours, Michael	[reply]

Replies are listed 'Best First'.

Re^2: OT: updating database question
by herveus (Prior) on Jul 23, 2007 at 11:51 UTC

Ack! Surrogate keys gone wild!

Seriously. My first thought is to wonder why the main tables use surrogate keys at all. In any case, adding a surrogate key to the third table doesn't necessarily add value.

If you want, say, to see all the qualifications Alice holds, you simply constrain the query to get them. The combination of name and qualification uniquely identifies the row already -- no surrogate key needed, along with its care and feeding.

yours,
Michael

[reply]