0

对于我正在制作的项目，我需要有可能（就像 stackoverflow 一样）保存所有以前的帖子编辑（修订）。

考虑我可以与帖子有一些 1 到 N 的关联（例如 1 个帖子关联 5 张图片）。

你会建议我如何为此设计数据库？
当然，帖子的 ID 应该保持不变，以免破坏 URL：

site/post/123 (whenever revisions it is)

对帖子的每个修订都应手动批准，因此您不能直接显示最后插入的修订。你会建议我如何设计数据库？

我已经硬了

Table: Post
postID | reviewID | isApproved | authorID |  text

和图像表（例如图像，但它可能是一切）

Secondary Table: Image
imageID | postID | reviewID | imagedata
4

2 回答 2

1

在全局信息和版本信息之间分离帖子的所有方面。换句话说，在修订中可以更改哪些内容以及始终适用于任何修订的内容。这些将是您的两个表中的字段，一个用于您的帖子，一个用于修订。您还需要一行来指定修订所针对的帖子以及修订是否被批准，并且在帖子表上，您需要一行来指定当前修订的内容。

于 2012-12-04T01:06:34.187 回答
1

实际上，我会将 post 表一分为二，一个是已批准的修订版，另一个是最新（未批准）的修订版。合理的是，任何不是最新的未经批准的修订都将被下一个取代（除非您真的想跟踪所有中间修改，无论是否批准）。

Table: OldPost
  postID | reviewID | authorID |  text

Table: PendingPost
  postID | authorID |  text

在该布局中，每当新修订被批准时，必须将其移至已批准的修订，但您不必在显示整个历史记录时将其过滤掉，相反，您不必过滤已批准的修订批准您网站的一部分。

您甚至可以使用另一个专用表格来优化布局，以用于最新批准的修订（因此总共三个表格用于帖子，不包括附件）。这种分区将提高站点对最常见查询的整体性能，但在您需要所有数据时会以更复杂的查询为代价（操作频率较低）。

Table: CurrentPost
   postID | authorID |  text

如您所见，此表结构与待处理帖子的表结构相同，因此更新将是微不足道的。将修订移动到旧的 post 表需要找出修订计数，但无论如何您都必须使用更经典的数据库布局来执行该操作。

关于附件表，布局似乎有效。

于 2012-12-04T01:14:06.220 回答