Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
nickfinity
Yak Posting Veteran
55 Posts |
 Posted - 2009-03-20 : 11:16:36
|
| Ok, dumb question time. I've got a database where most of the tables require the ability to add one or more comments to a record. Is it better practice to have a comments table and then have a TableAComments (and TableBComments, etc) table that contains only TableAID and CommentID? Or would it be better to have a TableAComments (and TableBComments, etc) table that actually contains the comments?Essentially, should the comments be broken up by table or should they be grouped together? Or does it really matter? Thanks for any help, I really appreciate it. |
|
|
visakh16
Very Important crosS Applying yaK Herder
52326 Posts |
Posted - 2009-03-20 : 12:46:22
|
| i think what you need is a single comments table with an id column. use this id column as a foreign key in what all tables you've comment details. then you may simply join onto comments table on this id to get corresponding detail for each table. |
 |
|
|
pootle_flump
1064 Posts |
Posted - 2009-03-20 : 13:36:55
|
quote:
Originally posted by visakh16
i think what you need is a single comments table with an id column. use this id column as a foreign key in what all tables you've comment details. then you may simply join onto comments table on this id to get corresponding detail for each table.
That would work if a row could have a single comment, and also that a comment might be shared by more than one row. As far as I can tell, that isn't the case.OP - Your problem with a single comment table is maintaining relational integrity. Whether or not you consider this an issue will determine your design.Personally, I would have a comment table related with a one-to-many relationship (assuming it is one to many and not many to many) for every table that requires comments.So one table for TableA comments, another table for TableB comments etc. |
|
|
|
visakh16
Very Important crosS Applying yaK Herder
52326 Posts |
Posted - 2009-03-20 : 13:40:55
|
quote:
Originally posted by pootle_flump
quote:
Originally posted by visakh16
i think what you need is a single comments table with an id column. use this id column as a foreign key in what all tables you've comment details. then you may simply join onto comments table on this id to get corresponding detail for each table.
That would work if a row could have a single comment, and also that a comment might be shared by more than one row. As far as I can tell, that isn't the case.OP - Your problem with a single comment table is maintaining relational integrity. Whether or not you consider this an issue will determine your design.Personally, I would have a comment table related with a one-to-many relationship (assuming it is one to many and not many to many) for every table that requires comments.So one table for TableA comments, another table for TableB comments etc.
sorry didnt get that.can you explain? |
|
|
|
pootle_flump
1064 Posts |
Posted - 2009-03-20 : 13:43:09
|
Mebbe I misunderstood your solution. Did you account for this?quote:
Originally posted by nickfinity
require the ability to add one or more comments to a record.
|
|
|
|
nickfinity
Yak Posting Veteran
55 Posts |
Posted - 2009-03-20 : 14:20:17
|
| Thanks for the help. I think I'll go with a table with comments for each table (I do want to maintain relational integrity). |
|
|
|
|
|
|
|
|
Basic design question