--- Andrew Kreps <[EMAIL PROTECTED]> wrote:
> On Thu, 6 Jan 2005 07:28:32 -0800 (PST), Stuart
> <[EMAIL PROTECTED]> wrote:
> > The problem I'm having a hard time getting my
> > around are those areas where they can have
> > entries.
> > One of the tables allows for a user to enter up to
> > 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
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