1 Reply Latest reply on Nov 7, 2013 2:54 PM by philmodjunk

    DB design - create new tables or not?



      DB design - create new tables or not?


           Creating a new DB.  I have a tour company that has  a lot of names and a few dozen hotels.   My first thought was just to use the Names table for my hotels, using a  Company field rather than first/last name fields.  I'm starting to think I should just create a Hotels Table,  rather than use the Names table as a generic placeholder for all types of names.  If creating Hotels table makes sense, since Names (of people) and Hotels both have addresses, would you suggest then to have an Address table that relates to both Names and Hotels, or is that just over engineering and unnecessary - just have Names with address fields, and Hotels with address fields?

           Is there a "generally preferred" way of doing this?



        • 1. Re: DB design - create new tables or not?

               There isn't a strict rule that you can apply to get an answer.

               The best answer depends on a number of factors. What besides "names" do you store in that table?

               Many contact manager systems set up a table of "contacts". In many cases, one record in the contacts table could represent either a person or an organization. That's due to the fact that many such systems need to store the same data (phone numbers, addresses, etc.) for either a company or an individual.

               In other cases, the database has to associate records with multiple individuals within a company. You might, for example, want the contact info for more than one individual that works for the same hotel or hotel chain. In those cases, you can set up one table for individuals and one for the organizations. Both can link to the same tables of address and phone number data if such are needed.