I did search before posting this question and didn’t find anything directly related, so if this is a duplicate I do apologize. I am designing a business system and like any business system I have a Customers table with a CustomerID PK Identity column.
I am working on the phone numbers/e-mail addresses tables which I would like to be normalized in such a way that any given CustomerID can have multiple phone numbers and/or e-mail addresses when the thought hit me. Most businesses will associate one phone number for any one person’s account and call that the primary phone number. This phone number would likely be the one displayed on any statements, reports, etc. The same with e-mail address.
I began thinking about how the SELECT query would work if I wanted to get a list of Customers with their primary phone and e-mail address. Obviously I could use an Inner Join to retrieve the information but I only want each CustomerID to show up once, if a CustomerID had two phone numbers then they would show up twice in the list.
So my initial thought was creating a table called CustomerCommunications and storing both phone numbers and e-mail addresses and adding a FlagPrimary column there but that doesn’t quite make sense because how would you tell if one record was a phone number or an e-mail address. (Obviously the content would give it away, but from the aspect of a query this would be challenging). So then I thought of adding a CommunicationTypes table with seperate rows for Primary Phone and Primary E-mail. Then in the CustomerCommunications table I would add a Foreign Key called CommunicationTypeID and that would allow me to easily identify which was a primary phone and which was a primary e-mail. But then I started thinking about what CommunicationTypeID the other phone and e-mail address records would be. Just Phone and E-Mail? Secondary Phone and E-Mail?
Obviously this question is subjective and subject to one’s own design ideas, but basically what I’m looking for is ideas other people have used when using a 1 to Many table but would like to be able to easily single out a row for display or reporting purposes.
First, you might want to think about keeping e-mail addresses and phone numbers in separate tables. Depending on your point of view, they have different attributes and purposes. If you do keep them together in one table then you should have a partitioning attribute to distinguish whether the information is a phone number or an e-mail address. If you use a code as your partitioning attribute then you have the option to add other communication types later, should the need arise.
If your business rule is that only one phone number and one address can be the primary ones and they can have as many of the others as you like, then the way to enforce this with the database schema is to put foreign keys on the customer table pointing at the contacts that are primary ones. This means your PHONE_NUMBER table has an FK to CUSTOMER and also CUSTOMER has an FK to PHONE_NUMBER (e.g. primary_phone_number_id). The same would be true for emails. If you mix your e-mails and phone numbers in the same table, you’re still going to need a trigger or some other procedural logic to ensure that you are pointing to one phone number and one email for each customer. This is another advantage of breaking your different contact types into their own tables. The FKs can do all the heavy lifting and you don’t have any potentially error prone procedural code.