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

我会采用更传统的方法来处理评论之间的外键关系以及它们所绑定的任何内容。

UNIVERSITY
  UniversityID // assuming primary key

COMMENTS
  CommentID // assuming primary key
  TypeID  // Foreign Key
  Type    // Name of the table where the foreign key is found (ie, University)

这对我来说感觉有点干净。一些关于使用另一个表的外键作为评论主键的一些感觉不对。

Answer 2

如果您使用UUID，则很难知道它来自哪个表。如果您只想查看实体到评论，就像在查询中一样，它将正常工作。如果你想查看评论并找出它的内容，你必须查看所有可能的表格（大学，建筑物等）才能找到答案。

使您能够对基本实体的键使用简单的顺序整数（通常需要可读性，索引碎片等）的一种可能性是使注释表的键包含两列。一个是注释适用的表的名称。第二个是该表的关键。这与Bryan M.建议的方法类似，但请注意，您无法将评论表中的外键实际定义为所有可能的父项。如有必要，您的查询将以双向方式工作，并且您无需担心UUID，因为表名+ ID的组合在整个数据库中都是唯一的。

Answer 3

好吧，因为似乎没有人愿意回答，我想我会坚持使用我的方法。但是，我仍然愿意接受其他建议。

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

3 个答案: