--- Andrew Kreps <[EMAIL PROTECTED]> wrote:

> On Thu, 6 Jan 2005 07:28:32 -0800 (PST), Stuart
> Felenstein
> <[EMAIL PROTECTED]> wrote:
> > 
> > The problem I'm having a hard time getting my
> hands
> > around are those areas where they can have
> multiple
> > entries.
> > 
> > One of the tables allows for a user to enter up to
> 5
> > choices. The table would look like this:
> > 
> I think you need to have a primary key that's unique
> per record.  That
> would allow you to make modifications per record
> without worrying
> about the duplicated RecordID.

I don't think it would kill me to add an auto inc
primary id.  Currently both the recordID and the
TypeID are set up as primary id's.  Also have a unique
index using both fields.  The recordID though should
be duplicated though as it ties the records from the
various tables together to form the profile.

> As far as updates and additions go, I usually keep
> the two separate
> when designing applications.  Being able to update
> multiple rows at
> once shouldn't be a problem, you just select all the
> data, display it
> to your users with the appropriate form elements
> (select boxes, check
> boxes and such), and index it in your form by the
> unique id field.

Okay, makes sense to me.

> I don't think it's necessary to delete the records
> and reload them,
> doing that adds database load and increases the
> chance that something
> will go wrong.  I hope I've touched on the items
> that concern you,
> feel free to write back if you need more
> information.

Thank you, I think I'm straight for now!


PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to