SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Database Design - Using a single common table for all 'Entities'


Database Design - Using a single common table for all 'Entities'

Author
Message
craigbroadman
craigbroadman
Valued Member
Valued Member (67 reputation)Valued Member (67 reputation)Valued Member (67 reputation)Valued Member (67 reputation)Valued Member (67 reputation)Valued Member (67 reputation)Valued Member (67 reputation)Valued Member (67 reputation)

Group: General Forum Members
Points: 67 Visits: 86
Hi

I am after a bit of advice.... I am considering the design for some tables in my database and wondered if anyone has any experience/ideas about the following structures.

Background Info
I need to created a CommunicationHistory table, this can hold communication history against a Customer, a Contact, a Job, a Task, a Product etc (could be associated to other things going forwards)

Option 1
I create nullable fields in the CommunicationHistory table for CustomerId, ContactId, JobId, TaskId, ProductId etc

Option 2
I create a table called 'Entity' that contains the common information about all 'Entities', e.g. EntityId, EntityTypeId, CreatedDate, CreatedByUserId...

Each of the Customer/Contact/Job/Task/Product tables have an EntityId FK field.

The CommunicationHistory table then has a FK to EntityId

Option 3
I create a CommunicationHistory table that stores all records and then linking tables for each entity e.g. CustomerCommunicationHistory(CommunicationHistoryId, CustomerId) , ContactCommunicationHistory(CommunicationHistoryId, ContactId), JobCommunicationHistory(CommunicationHistoryId, JobId) etc...


-----------------------------------------
What do you think? Are there any other options?

Thanks in advance for your help and suggestions.
Orlando Colamatteo
Orlando Colamatteo
SSC Guru
SSC Guru (78K reputation)SSC Guru (78K reputation)SSC Guru (78K reputation)SSC Guru (78K reputation)SSC Guru (78K reputation)SSC Guru (78K reputation)SSC Guru (78K reputation)SSC Guru (78K reputation)

Group: General Forum Members
Points: 78918 Visits: 14499
craigbroadman (8/31/2012)
Hi

I am after a bit of advice.... I am considering the design for some tables in my database and wondered if anyone has any experience/ideas about the following structures.

Background Info
I need to created a CommunicationHistory table, this can hold communication history against a Customer, a Contact, a Job, a Task, a Product etc (could be associated to other things going forwards)

Option 1
I create nullable fields in the CommunicationHistory table for CustomerId, ContactId, JobId, TaskId, ProductId etc

Option 2
I create a table called 'Entity' that contains the common information about all 'Entities', e.g. EntityId, EntityTypeId, CreatedDate, CreatedByUserId...

Each of the Customer/Contact/Job/Task/Product tables have an EntityId FK field.

The CommunicationHistory table then has a FK to EntityId

Option 3
I create a CommunicationHistory table that stores all records and then linking tables for each entity e.g. CustomerCommunicationHistory(CommunicationHistoryId, CustomerId) , ContactCommunicationHistory(CommunicationHistoryId, ContactId), JobCommunicationHistory(CommunicationHistoryId, JobId) etc...


-----------------------------------------
What do you think? Are there any other options?

Thanks in advance for your help and suggestions.


Learning more about how this data will be used could affect the choice, but based on what you have posted I would lean in the direction of Option 3 initially. CommunicationHistory (consider calling it simply Communication) would store properties common to communications across all entities. Your linking tables would then offer flexibility to store properties relevant only to each specific entity.

Option 1 is what I label a 'spreadsheet approach.' It's very flat, will be easy to report on and for users inexperienced with joins to query, but is inefficient in terms of storing new data, and can devolve into something with hundreds of columns in the worst case.

Option 2 tried to skirt the relational model. It creates a problem for me because it stores different entities in the same table. Each row should describe one thing, and not the 'same abstracted thing' like an 'entity.'

__________________________________________________________________________________________________
There are no special teachers of virtue, because virtue is taught by the whole community. --Plato
Tom Thomson
Tom Thomson
SSC-Dedicated
SSC-Dedicated (39K reputation)SSC-Dedicated (39K reputation)SSC-Dedicated (39K reputation)SSC-Dedicated (39K reputation)SSC-Dedicated (39K reputation)SSC-Dedicated (39K reputation)SSC-Dedicated (39K reputation)SSC-Dedicated (39K reputation)

Group: General Forum Members
Points: 39654 Visits: 12890
Like opc.three, I would go for option 3. As well as being a truly relational approach (unlike option 2) it is probably reasonably storage efficient.

Option 3 also has the advantage that it is easy to solve what I suspect will be the next problem that you hit: a communication may have different attributes depending on whether it is a customer communication or a job communication or a something else communication, and you need somewhere to put these attributes: the linking tables in option 3 are a suitable place - of course they will then be something more than just linking tables; the communicationhistory table isn't because it has only information common to all communication types and the customer and job and something else tables aren't because they contain attributes of a customer (or a job or whatever) and not attributes of communications. Trying to handle this in option 2 would be problematic, in option 1 it would lead to a proliferation of nullable columns.

Tom

craigbroadman
craigbroadman
Valued Member
Valued Member (67 reputation)Valued Member (67 reputation)Valued Member (67 reputation)Valued Member (67 reputation)Valued Member (67 reputation)Valued Member (67 reputation)Valued Member (67 reputation)Valued Member (67 reputation)

Group: General Forum Members
Points: 67 Visits: 86
Excellent.

Thank you for your suggestions.... Option 3 it is then! :-D
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum







































































































































































SQLServerCentral


Search