如何解决评论系统设计
| 这是我当前的评论系统设计： 我正在为一个包含许多领域，博客，教程，手册等的网站进行开发。应该为每个（tblBlogComments
tblTutorialComments
tblComment
-------------
Section (int)
SectionIdentifier (int)
Section
Blog = 1
Articles = 2
Tutorials = 3
...
ViewBlog.aspx?ID=5
Section = 1
SectionIdentifier = 5
解决方法
在Codd为关系模型设计的原始模型中，外键可以引用不同表中的多个主键，并且如果任何一个表包含该值，则引用完整性是有效的。
不幸的是，正如您所注意到的，SQL不能提供这种功能，这是对原始想法的苍白反映。
一种标准的解决方法是创建一个新的关系，该关系包含其他所有键。但是，在这种情况下，这并不是一个很好的解决方案，因为如果同时发生大量插入操作，则会引起争用。
我要处理的方法是创建一个值（我们称它为Comment-Anchor），您可以将其放入每个要添加注释的表中。该值（与设计良好的数据库中的所有其他键不同）应为GUID。然后，每个注释可以具有一个注释锚，该注释锚指示该注释所引用的值。
通过使其成为GUID，您始终可以在博客或教程等中插入唯一值，而不会发生争用。您不必在任何地方维护评论锚的主列表，也没有任何节与任何其他节竞争或被其阻止。
例如，这对于查找单个博客条目的所有评论的正常用例将非常有用。换句话说，从注释到要注释的事物，您可以在注释表中放置一个标志，以标识要刷新的表，但是我不会这样做。我只搜索所有表格，也许带有视图或其他内容。反向查询非常少见，以至于我看不到为其维护基础结构有什么要紧，并且标志将是冗余数据，这是RDBMS的祸根。
该系统的另一个好处是它易于扩展。如果您创建一种新的数据类型，或决定向现有数据类型添加注释，则只需在表中添加“注释锚点”列。在数据库端不必执行任何其他工作。甚至处理注释的中间件部分也无需进行任何修改，因为它不知道注释采用哪种类型的东西。
,对于表设计，在这种情况下，我将尽可能地模拟类结构。根据您所说的，（大致）如下所示：
Section <- Post <- Comment
interface IComment
{
int ID {get; set; }
int Section {get; set; }
....
}
class BlogComment : IComment
{
....
}
class TutorialComment : IComment
{
....
}
class WebControl
{
IComment _comment = null;
public WebControl(IComment comment)
{
_comment = comment;
}
}
public static void main()
{
var creater = new CommentCreater();
IComment comment1 = creater.CreateBlogComment()
WebControl webcontrol = new WebControl(comment1);
......
IComment comment2 = creater.CreateTutorialComment()
webcontrol = new WebControl(comment2);
........
}
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。