Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

Database Design - Using a single common table for all 'Entities' Expand / Collapse
Author
Message
Posted Friday, August 31, 2012 2:39 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, April 8, 2014 6:04 AM
Points: 9, 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.
Post #1352647
Posted Friday, August 31, 2012 10:48 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 7:44 PM
Points: 7,107, Visits: 12,661
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
Post #1352971
Posted Wednesday, September 5, 2012 11:07 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 6:16 PM
Points: 7,738, Visits: 9,487
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
Post #1354767
Posted Wednesday, September 12, 2012 3:45 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, April 8, 2014 6:04 AM
Points: 9, Visits: 86
Excellent.

Thank you for your suggestions.... Option 3 it is then!
Post #1357865
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse