--- Andrew Kreps <andrew.kreps@xxxxxxxxx> wrote: > On Thu, 6 Jan 2005 07:28:32 -0800 (PST), Stuart > Felenstein > <stuart4m@xxxxxxxxx> 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! Stuart -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
