Home Forums Database Design Design Ideas and Questions Database Design - Using a single common table for all 'Entities' RE: Database Design - Using a single common table for all 'Entities'

  • August 31, 2012 at 10:48 am

    #1532526

    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