A wise man once taught me, "organization is the key to success".
Put all the data in the same table you have. 200k people is nothing for mySQL to handle, and the cost of an extra JOIN is going to be a nightmare to deal with all the time. I thought I learned/read somewhere a long time ago that using 'NULL' values was sub-optimal and should be avoided if possible. Perhaps that is dated information now? I only use them when needing to know if a field has not been set as apposed to set but with no value. So effectively a 'trinary' state, rather than 'binary'. If you have NULL, you know that field is not set, but having a 0 (default) you don't know if the value is truly 'false' or 'not set'. > -----Original Message----- > From: Afan Pasalic [mailto:[EMAIL PROTECTED] > Sent: Friday, October 05, 2007 8:42 AM > To: mysql@lists.mysql.com > Subject: do I need two tables or one will do just fine? > > hi, > I have a employees table (first name, last_name, address, > city, state, > zip, phone,...). > though, I got a requested to add additional info about people, like > phone_extension, zip+4, nick, DOB... that will not be used very often. > what would be better solution: > a) add these columns to employees table > b) create separate table employees_addition_info with these > fields and > store info if any (with employee_id of course) > > one friend of mine suggest me to keep all data in one table since the > "empty" fields will be NULL and there will not be a lot of wasted > space. specially because I'll never have more than 200K > records (right > now I have about 50K records). and "normalization" will not > improve a lot? > > any suggestions? > > thanks. > > -afan > > -- > MySQL General Mailing List > For list archives: http://lists.mysql.com/mysql > To unsubscribe: > http://lists.mysql.com/[EMAIL PROTECTED] > > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
