首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >问答首页 >评论系统设计

评论系统设计
EN

Stack Overflow用户
提问于 2011-04-15 22:22:46
回答 4查看 3.3K关注 0票数 5

这是我目前的评论系统设计:

我正在为一个网站开发它,它有很多领域,博客,教程,手册等。作为开发每个(tblBlogCommentstblTutorialComments)等单独的评论表等,我试图去一个结构适合所有人的方法。

这样,我就可以把评论系统变成一个web控件,然后把它放在我想要评论的任何页面上。这意味着我只需要维护一组规则和一组代码文件。

唯一的问题是,想出了一个“很好”的方法来确定哪个部分(博客/教程/手册)属于哪个部分。

例如,一种解决方案是:

代码语言:javascript
运行
复制
tblComment
-------------
Section (int)
SectionIdentifier (int)

其中'Section‘映射到站点的每个部分的唯一,EG:

代码语言:javascript
运行
复制
Blog = 1
Articles = 2
Tutorials = 3
...

SectionIdentifier是该页面的某种唯一ID,例如:

代码语言:javascript
运行
复制
ViewBlog.aspx?ID=5

这应该是片段1,标识符5。现在,带有Section = 1SectionIdentifier = 5的评论表示它是对5号博客条目的评论。

这很有效,但以可维护性和坚实的结构为代价,因为SectionIdentifier是匿名的,无法建立任何关系。

这样的设计可以吗,或者有更好的解决方案(例如,使用某种父表来添加注释?)

EN

回答 4

Stack Overflow用户

回答已采纳

发布于 2011-04-15 22:54:11

在Codd最初为关系模型设计的代码中,一个外键可以引用不同表中的多个主键,如果任何一个表包含该值,则引用完整性是有效的。

不幸的是,SQL与最初的设想相去甚远,因为它没有提供这种能力,正如您已经注意到的那样。

一种标准的解决方法是创建一个新的关系,该关系持有所有其他关系的密钥。但在这种情况下,这不是一个很好的解决方案,因为如果多个插入同时发生,则会产生一个争论点。

我的处理方法是创建一个值-让我们称其为Comment-Anchor-您可以将其放入每个要添加注释的表中。这个值(与设计良好的数据库中的所有其他键不同)应该是一个GUID。然后,每个注释都可以有一个Comment-Anchor,指示它引用的是哪个值。

通过将其设置为GUID,您可以始终在博客或教程或其他内容中插入唯一值,而不会发生争用。您不必在任何地方维护Comment-Anchors的主列表,任何部分都不会与任何其他部分竞争或被任何其他部分阻止。

例如,这将很好地用于查找单个博客条目的所有评论的正常用例。反过来,从注释到被注释的内容,您可以在注释表中放置一个标记来标识哪个表正在被引用,但我不会这么做。我只会搜索所有的表,可能会有一个视图或其他什么。反向查询非常少见,我看不出维护它的基础设施有多大意义,标志是冗余数据,这是RDBMS的祸害。

这个系统的另一个好处是它很容易扩展。如果您创建了一种新类型的数据,或者决定向现有类型的数据添加注释,则只需将Comment-Anchor列添加到表中。在数据库端不需要做额外的工作。甚至处理注释的中间件部分也不需要以任何方式进行修改,因为它不知道接受注释的是哪种类型的内容。

票数 3
EN

Stack Overflow用户

发布于 2011-04-15 22:39:25

对于表设计,我会尽可能地将其建模为与本例中的类结构相似的模型。根据您所说的,它看起来(大致)是这样的:

Section <- Post <- Comment

所以,你会有:

  1. a Section表格(例如博客、文章、教程等)
  2. a Post table (针对每个部分中的单个帖子)
  3. a comments table (针对每个帖子的评论)

每个帖子都有一个对它的部分的引用,每个评论都有一个对它的帖子的引用。DB可以将引用作为漂亮、干净的外键,类可以在应用程序需要时在关系的一侧或两侧具有列表。

对我来说,这似乎是一个很好的,简单的,灵活的结构,不会使事情复杂化,并且仍然允许你挂起额外的东西,比如编辑和投票。

票数 2
EN

Stack Overflow用户

发布于 2011-04-15 22:49:17

我会避免创建一个id列,该列根据同一表中的另一列定义不同的关系。例如,在您的示例中,根据Section的值,SectionIdentifier可以表示任意数量的外键引用。这使我在一般原则上感到厌烦。它还保留了现代RDBMS平台的几个好处,因为它不受支持。

对于这些不同的部分,您的总体架构是如何布局的?我使用过一些CMS,它们要求每个部分共享一个通用的基本实体,称为“模块”或“插件”。然后,给定模块的每个实例都有自己的id,用于映射到该特定实例所需的任何内容。

如果这对您来说是一个可行的架构方向,您还可以使用该ModuleInstanceID作为注释的外键。您只需决定如何将给定类型的模块/插件注册为有效的注释目标。

无论如何,你能说明一下你的部分是如何在引擎盖下组合在一起的吗?

票数 1
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/5678166

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档