what you describe is called 'normalization'; if you'll always only have 20 people in a table it may not be worth it for you - though it's poor practice to continue to design tables in this fashion. come up with a nice naming convention and design tables that break contact information such as name, address, etc. away from other information, such as username and password. breaking out site prefs is a good idea, too becuase you may or may not need to call these prefs every time you do a page load. regardless it's good practice to seperate information not pertinent to the other fields. another thing you should consider is if someone has more than one address - such as a po box and a home address... would you require them to choose only one? if you require a one-to-many relationship then you may want to break this out; contact from user and prefs all in seperate tables. mysql has built-in checking with innodb tables to reference foreign keys to do error-checkign for you (ie referencing someone that doesn't even exist or deleting a recordd that has information referencing it).
http://www.phpbuilder.com/columns/barry20000731.php3 ~Phillip "André cerqueira" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > i think if the most accessed fields are much smaller than the hole > thing, you can consider splitting it > whats the average size of your records? > whats the size of the fields you access the most? (check your sql's for > that one...) > amount of records would influence that decision too > > btw, if they are all 0/1 preferences, maybe you could put them all in a > single field using set or some int type with 1 bit for each preference > (int would be enough for 32 preferences flags) > > > Monty wrote: > > I have a member DB table that has about 50 fields in it for each record. It > > holds things like username, password, mailing address, and general site > > preferences. > > > > I'm wondering if I will see any noticeable speed increase if I were to split > > the 20+ fields that hold preferences (nearly all are single-digit 1/0 > > fields) out from the other fields that hold general member data, and put > > them into their own table? Or maybe there's some other good reason for doing > > this that I'm not aware of? > > > > I'd actually prefer to keep it all together, because it's a lot easier to > > update a single table in MySQL than several if a member makes changes to > > their account or preferences. > > > > What do you think? > > > > Monty. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFAOo/WaxdA/5C8vH8RAq6mAJ49bHhJbFDxPvwU16HSc2DiLRjLJwCaAhoi > SyJaWOebs87TP+eDC53foNc= > =5Rhw > -----END PGP SIGNATURE----- -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
