Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

 All Forums
 General SQL Server Forums
 Database Design and Application Architecture
 Is this table structure valid/sound?

Author  Topic 

Dbar
Starting Member

12 Posts

Posted - 2008-12-16 : 08:27:08
I have several tables in my application that can be associated with 0-many contacts in a contacts table. For example, each task in the Tasks table can be associated with several contacts/individuals (Manager, Scheduler, Planner, etc.); the same is also true with the Projects table, the Contracts table, etc. A contact can serve in several “roles” --- e.g., John Doe could be the manager of a project, the “approver” of a contract, etc.

I created the following table structure for handling contacts to avoid the need for multiple “child” contacts tables (i.e., “TaskContacts”, “PurchaseOrderContacts”, “ProjectContacts”, ContractContacts, etc.):

Roles: PK=RoleID (auto-generated)…..(this table defines contact roles “Manager”, “Planner”, etc.)
Contacts: PK=ContactID (auto-generated)…. (this table defines contacts/individuals “John Doe”, etc.)
ContactGroups: =ContactGroupID (auto-generated)…(this table contains just one field, the PK (I’ll come back to this later)
ContactRoleGroup: PK= ContactGroupID, ContactID this table is an intersection table for the previous 3 tables.. contains RoleID, ContactID, and ContactGroupID)

Each of the tables that are associated with multiple contacts (i.e., Tasks, Projects, etc.) contains the field ContactGroupID, which links it to a group of contacts.

This structure seems to work, but I’m wondering if it is “sound”. The sole purpose of the ContactGroups table is merely to group all contacts in the ContactRoleGroup table.

Here is an example with data:

Roles --- PK=1, “Manager”; PK=2, “Scheduler”; PK=3, “Planner”
Contacts --- PK=1, “John Doe”
ContactGroups --- PK=1
ContactRoleGroups --- this is the intersection of the previous 3 tables (ContactID, ContactGroupID, RoleID) --- Record1=1,1,1 … Record2=1,1,2… Record1=1,1,3

Is this structure sound? It does eliminate the need for numerous “child” contact tables (e.g.”TaskContacts”, “ProjectContacts”, etc). However, I’m concerned that the ContactGroups table only has one field (i.e., the auto-generated PK)

Thanks!

Lumbago
Norsk Yak Master

3271 Posts

Posted - 2008-12-16 : 11:07:30
As far as I can understand this is the beginning of a so-called EAV-model (Entity - Attribute - Value) and can give you some serious challenges when you realise that you need to make additional tables with properties for each role. There are numerous articles on this (google "sql eav"), and here's one: http://weblogs.sqlteam.com/davidm/articles/12117.aspx

And about this one column table; I don't get it. I don't think you could ever in a million years defend having a table with only one column but I might be wrong. If you add another column called ContactGroupName however, it's a different story.

- Lumbago
Go to Top of Page
   

- Advertisement -