<a href="http://g.adspeed.net/ad.php?do=clk&zid=15220&wd=468&ht=60&pair=as" target="_blank"><img style="border:0px;" src="http://g.adspeed.net/ad.php?do=img&zid=15220&wd=468&ht=60&pair=as" alt="i" width="468" height="60"/></a>
Log in
::
Register
::
Not logged in
Home
Tags
Articles
Editorials
Stairways
Forums
Scripts
Videos
Blogs
QotD
Books
Ask SSC
SQL Jobs
Training
Authors
About us
Contact us
Newsletters
Write for us
<a href="http://g.adspeed.net/ad.php?do=clk&zid=15491&wd=120&ht=300&pair=as" target="_top"><img style="border:0px;" src="http://g.adspeed.net/ad.php?do=img&zid=15491&wd=120&ht=300&pair=as" alt="i" width="120" height="300"/></a>
Recent Posts
Recent Posts
Popular Topics
Popular Topics
Home
Search
Members
Calendar
Who's On
Home
»
Database Design
»
Design Ideas and Questions
»
Database Design - Using a single common table...
Database Design - Using a single common table for all 'Entities'
Rate Topic
Display Mode
Topic Options
Author
Message
craigbroadman
craigbroadman
Posted Friday, August 31, 2012 2:39 AM
Forum Newbie
Group: General Forum Members
Last Login: Tuesday, October 02, 2012 2:22 AM
Points: 9,
Visits: 85
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
opc.three
opc.three
Posted Friday, August 31, 2012 10:48 AM
SSCertifiable
Group: General Forum Members
Last Login: Yesterday @ 8:27 PM
Points: 6,735,
Visits: 11,788
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
Believe you can and you're halfway there.
--Theodore Roosevelt
Everything Should Be Made as Simple as Possible, But Not Simpler
--Albert Einstein
The significant problems we face cannot be solved at the same level of thinking we were at when we created them.
--Albert Einstein
1 apple is not exactly 1/8 of 8 apples. Because there are no absolutely identical apples.
--Giordy
Post #1352971
L' Eomot Inversé
L' Eomot Inversé
Posted Wednesday, September 05, 2012 11:07 AM
SSCertifiable
Group: General Forum Members
Last Login: Yesterday @ 12:25 PM
Points: 7,110,
Visits: 7,184
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
Is minic a gheibheann béal oscailte dorn dúnta.
Is minig a cheapas beul fosgailte dòrn dùinte.
Post #1354767
craigbroadman
craigbroadman
Posted Wednesday, September 12, 2012 3:45 AM
Forum Newbie
Group: General Forum Members
Last Login: Tuesday, October 02, 2012 2:22 AM
Points: 9,
Visits: 85
Excellent.
Thank you for your suggestions.... Option 3 it is then!
Post #1357865
« Prev Topic
|
Next Topic »
Permissions
You
cannot
post new topics.
You
cannot
post topic replies.
You
cannot
post new polls.
You
cannot
post replies to polls.
You
cannot
edit your own topics.
You
cannot
delete your own topics.
You
cannot
edit other topics.
You
cannot
delete other topics.
You
cannot
edit your own posts.
You
cannot
edit other posts.
You
cannot
delete your own posts.
You
cannot
delete other posts.
You
cannot
post events.
You
cannot
edit your own events.
You
cannot
edit other events.
You
cannot
delete your own events.
You
cannot
delete other events.
You
cannot
send private messages.
You
cannot
send emails.
You
may
read topics.
You
cannot
rate topics.
You
cannot
vote within polls.
You
cannot
upload attachments.
You
may
download attachments.
You
cannot
post HTML code.
You
cannot
edit HTML code.
You
cannot
post IFCode.
You
cannot
post JavaScript.
You
cannot
post EmotIcons.
You
cannot
post or upload images.
Copyright © 2002-2013 Simple Talk Publishing. All Rights Reserved.
Privacy Policy.
Terms of Use.
Report Abuse.
