I have one table that saves comments for a varied set of content types. These are saved in other tables (news, articles, users). I wonder what’s the best way to connect these tables? In previous projects I used a second table for each kind of content. They held the id of the certain content mapped to ids of the comments table. So for each comment I had the comment entry itself and a ‘connector’ entry. An alternative would be to use a separate comments table for any kind of content. At the end both ways contain some redundancy flaw.
So which one should I use or is there the ONE solution?
There are a few obvious ways to design your table:
1) You can have a master Comments table, and intermediate tables to connect each comment to your Articles, News, and Users tables:
Advantage of this is the relative ease of querying comments for each feature. However, this style suffers from referential integrity: its possible to connect a single comment to multiple comments, news articles, and users. Additionally, its not very scalable: if you add comments for RSS feeds, favorite links, user status, etc, then you have intermediate tables for all of those types.
2) Another approach is a slightly denormalized version:
This works and it scales easily whenever you add new features, but you can’t key your Comments.RefID field to multiple tables simultaneously, so you lose referential integrity.
3) The final option requires lots of redundant ‘comments’ tables for each feature.
Advantage of this style is the preservation of referential integrity, and that its readily understanable to anyone looking at your schema. Disadvantage is the excessive number of tables with an identical schema.