网站评论系统的数据库结构

Question

我正在开发一个目前需要评论系统的网站.由于这个网站是全新的,并且数据库结构还没有一成不变,我想就如何最好地处理评论系统提出一些建议,例如:

• 评论必须能够放在任何东西上.在未来的表格中包含项目.
• 评论必须快速(并且容易？)可查询.

我知道仅此一点并不多,所以这里有一个想法:每个大学都有大学,每个学院都有建筑物,每个大楼都有房间.每个用户都应该能够评论这四个项目中的任何一个(以及我们稍后可能添加的未来),但我想避免为每个项目制作一个评论表.

我提出的这个解决方案似乎有效,但我也对其他想法持开放态度.我的解决方案是使用UUID作为每个项目(大学,学院,建筑,房间)表的主键,然后在注释表中将引用ID设为UUID.虽然我不认为我可以建立一个外键系统来链接所有内容,但我相信没有什么会破坏,因为只有可用的项目可能有注释,因此一个项目可以没有注释,或者如果它被删除,那么评论根本不会被退回.

University:
    UniversityID - CHAR(36)  //UUID()       & primary key
    ...

Comments:
    CommentID - CHAR(36)     //UUID()       & primary key
    CommentItemID - CHAR(36) //UUID of item & indexed
    CommentUserID - INTEGER
    CommentBody - TEXT

然后查询将显示为:

SELECT * FROM University, Comments WHERE UniversityID = CommentItemID;

所以你们都在想什么？这个系统规模是否会包含大量数据,或者是否有更好的(可能是最佳实践或模式)方式？

我提前谢谢你.

编辑1: 我已将注释定义更改为包含主键和索引列,以解决迄今为止引发的问题.通过这种方式,系统也可以对注释进行评论(不确定这在实际代码中会有多么混乱,但它对我来说有一定的数学完整性).我希望系统尽可能保持相似,直到我接受了答案.

到目前为止,Sebastian Good和Bryan M.的两个答案都提出了两个整数的双主键,如ItemID和TableID.我对这种方法的唯一犹豫是,我要么必须有一个新表列出TableID及其相应的字符串表名,要么将全局变量引入我引用它们的代码中.除非我缺少另一种方法,否则这似乎是额外的代码,可以避免给我.

你们都觉得怎么样？

Answer 1

好吧，既然没有人愿意回答，我想我会坚持我的方法。不过，我仍然愿意接受其他建议。