[thelist] Database - advantage of mulitple tables?

rogerharness at comcast.net rogerharness at comcast.net
Mon Aug 17 11:14:28 CDT 2009



We’re working on a database in my office, that will be used to track training. Currently, we have an employee table with a little over 4000 names, that contains such info as: UserID, UserLName, UserFName, UserClassification, UserRegionDivision, UserEmail, UserCity, UserEmpStatus, UserSupervisorLName, and a few others. Can you help explain why (or why not!), it would be good to break down some of this info into multiple tables? I’m thinking we should at least have a User table, a Classification (position) table, and a RegionDivision table. But the only reasons I can come up with would be in case we needed to change any of these fields, we’d only have to edit the Classification or RegionDivision table and not have to go through the entire employee table. Is this correct? 


Would there be other reasons we should try to create multiple tables, or would it be simpler just to have the one large table? With only 4000 rows for this table, would speed be an issue at all, either way? 


I’m definitely not a true DB person, but I’m still having to take this on, so I’d like to prepare as much as possible before I get myself into trouble. 


Thanks as always folks! 

-Roger Harness

More information about the thelist mailing list