I’m currently working on creating electronic version of various request forms. Each form will more than likely require some specific data about the user. For sake of argument, here’s a simplified version.
Form Required Info ¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ Mileage Claim Does user have a lease car? Overtime Claim Contract type (permanent/temp). Salary Procurement Request User role (supervisor, technician)
I currently don’t know how many forms in total will end up on this system, or what other extra information about the user they may need. But it’s safe to assume they’ll all require standard stuff like name, email, payroll number etc.
What approach would you take to model this? Throw it all into the users table or create lots of tables that reference User?
Throwing it all into the users table is a recipe for a growing ‘Ball of Mud‘ pattern. Eventually you’ll have a table with 300 fields – first name, last name, address, work address, summer address, ownsaleasecar, likespizza, ….
I’d have them all share a user object. The user would reflect what they all held in common. If they used different kinds of users (e.g. some where people who had personal information, and some were, say, employees with entirely different datasets) it might be reasonable to have users and employees, or some such. The main point is that I wouldn’t try to shoehorn different types into the same table.
edit- an additional point is that glomming different datatypes together makes enforcing integrity impossible – suppose you have ‘RentalCarUser’ and ‘EmployeeUser’ grouped into the same table, and you have the field ‘DoesUserHaveLeaseCar’ for the RentalCarUsers. Well, then, it’s going to be null or have a meaningless default for the Employees, and if you actually want to enforce that every rental car user has to have that information, you can’t enforce it on the database level (field !=null) because you’ve got additional users for whom that value isn’t applicable. Adding a trigger to fill in ‘NA’ for the Employees doesn’t help, because you’ve then got a whole bunch of records with ‘NA’ and you can’t easily tell if that’s correct or missing data.