15

I've been working on laying out the data structure for an application I'm working on. One of the things it will need to handle is storing customer / contact information. I've been studying the interface of a few different contact information programs like Address Book, gmail contacts, etc.

I have basically boiled the contact down to an "entity" (individual, company, role, etc).

  • Each Entity can have multiple Address, Phone, E-Mail entries.
    • Each of these defines a "relationship" (home/work/assistant, etc)
    • Entity {1} --{relationship}--> {0..*} Data
  • An Entity can have multiple fields that are freeform data storage for other "generic" data (birthdays, AIM account, etc)
    • Entity {1} --{fieldName}--> {0..*} Field Data
  • An Entity can link to another Entity for instance as a employee, spouse
    • Entity {0..} <--{relationship}--> {0..} Entity

Has anyone done any SQL implementations of similar contact databases? Any insight/suggestions/pitfalls to avoid that you could share with someone trying to work on a project by themselves here? Does what I have described seem reasonable or overcomplicated?

One question, lets say you have 4 people who all work for the same company. They all have the same "work" phone number (perhaps with a different extension) - If the number or address for "work" changes, I'd like to be able to update the contacts fairly easily. Now a lot of this comes down to how you would use the database. I'm thinking that this becomes a matter of linking employee's to their respective company entities, but then the address/phone number is no longer directly connected to the employee. I'm kind of debating making the Entity/data relationship many to many allowing you to attach the same mailing address/phone number to multiple people, and updating it in one place can update it in all places. Am I just over thinking this? pulls out hair

Matt
  • 22,721
  • 17
  • 71
  • 112
gnarf
  • 105,192
  • 25
  • 127
  • 161

4 Answers4

17

It's a bit trite, but you need to know your data and what you're going to do with it before you start thinking tables.

I'd suggest looking at Object Role Modeling (or this too) to define the model in plain English before you actually implement any tables. I use this VS plugin: NORMA that will also generate a schema for you too.

Alternatively, there are a bunch of data models here that may inspire you. This is "Contact Management" but there are others, such as the "Customers" section

(I just wanted to post an image..) Contact Management
(source: databaseanswers.org)

Glorfindel
  • 21,988
  • 13
  • 81
  • 109
gbn
  • 422,506
  • 82
  • 585
  • 676
  • Great resource follow up with the link – John Lechowicz Dec 02 '09 at 20:29
  • 1
    Thanks for the links, definitely some helpful ones there. The layout in that image seems very much like what I started thinking about with the many/many relationship `Customer_Addresses`... I also am thinking that this might over complicate the maintenance of updating/entering information. I.E. How do you select the "same address" as another contact vs. duplicating the address in the table. – gnarf Dec 02 '09 at 20:51
  • @gnarf: I haven't used or analyzed this model, sorry. I just know the site – gbn Dec 02 '09 at 20:57
  • no problem, still inspirational... just putting my thoughts out in the open :) – gnarf Dec 02 '09 at 22:24
  • http://www.databaseanswers.org/data_models/ is a "Reported Attack Page" by Google :( – jww Dec 25 '11 at 04:30
4

This is just to help with your second question; where phone extension actually belongs to relationship between person and company entities.

contact_model_01

Damir Sudarevic
  • 21,891
  • 3
  • 47
  • 71
2

Microsoft offers a number of starter databases schemas, including Assets Maintenance, Contact Management, Customers and Orders, Document Management, e-Commerce, Help Desk, Issue Tracking Software, Retail Inventory Control, and Product Catalogs. See Starter Database Schemas.


EDIT (April 2016): It appear the Microsoft webmaster broke the link. Here's the Wayback Machine archive of the page.

jww
  • 97,681
  • 90
  • 411
  • 885
  • @Henry. It looks like the Microsoft Webmaster broke the link. You should probably contact Microsoft at ssedmf@microsoft.com, and ask them to fix it. The email address was provided at the Starter Database page as a point of contact. But I would not be surprised if the Microsoft Postmaster broke that email address, too. – jww Apr 06 '16 at 01:46
1

A couple of points that tend to crop up in my experience..

Consider reciprocal relationships. For example, if someone is defined as being an employee of a company, then the company is then by definition the employer of that person.

Are you considering addresses as entities in themselves, or as merely free text associated with a person/place? In some applications, the address (physical building etc) is 'real' and only one can exist in the table. (Often using the government/postal identifier for it).

Garry
  • 1,291
  • 1
  • 11
  • 19
  • Yeah - Reciprocal relationships were already in the works, I was figuring you could define **A** is an *employee of* **B** and therefore, **B** has *employee* **A** as well. - Yes, addresses are intentionally going to be their own table, I'm trying to lower the chances of having duplicate address information in the table by making it potentially a many to many relationship. Same with phone numbers.. I'd like to know if bob has the same # as joe... – gnarf Dec 02 '09 at 21:06