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

  • 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.

  • 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

  • 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

  • Excellent.

    Thank you for your suggestions.... Option 3 it is then! 😀

Viewing 4 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic. Login to reply