Database structure for "flag as spam" functionality

I have created a webapp with php/mysql.

In my application I have different section, where user submits contents, like photos, news, stories, videos etc.

All these are separate sections with their separate story details pages. I want to apply a "Flag as Spam" functionality for all sections, but confused with database. Should I create separate table for every section such as table name: video_spam or photo_spam or should I go with one table spam_contents which will contain following columns.

• SpamId - unique id for the table
• ByUserId - Who marked it as spam
• SectionName - will be 'news', 'video', 'stories' etc.
• Reason - Reason for which user marked it as spam
• ContentId - This will contain photoid or videoid or newsid
• Date - The day user marked content as spam.

If I need to fetch all content of video section, which is marked as spam by users then I can get it on the basis of SectionName and ContentId.

Will it be a good approach or anyone has any better solution for this scenario.

Please hel开发者_JAVA技巧p, Thanks!

---

Unless there's something unique to "video spam", or something unique to "photo spam", etc., you're almost certainly better off with a single table.

Your situation is similar to this supertype/subtype issue. See my reply to that question, too.

---

I believe this looks like the best way. Having a centralized collector with a unique purpose is a design plus, imho. You can surely go for some more fields in each table (ex. video_table has also a 'spam_flag','flag_by','flag_date' and whatever along these lines), but I think this, a part from multiplicating your work just in creating, may have significatn drawbacks whenever you need to make adjustement or changes to the system.

And, by the way, I've seen this structure implemented in a couple of well-known open source Bullettin Boards for reported messages and similar, so I believe it's a valid and optimized design.

Alternatively, if you feel in good mood, you could also make both: something 'detailed' pertaining to each table, and a centralized structure as a sort of 'admin panel report'.