协作文章编辑器的良好表结构答案

【问题标题】：Good table structure for collaborative article editor协作文章编辑器的良好表结构
【发布时间】：2011-06-15 04:27:57
【问题描述】：

我有一个应用程序，它允许管理员上传文章并与许多用户共享以进行编辑。然后将文章分解为句子，这些句子将作为单独的行存储在 MySQL DB 中。每个用户一次可以编辑一个文章句子。如何构建数据库以允许管理员调整文章句子（合并、移动、删除、编辑、添加）并仍然保持用户与文章句子关系的完整性？这是基本结构：

article_sentences
---------------
-id (auto_increment)
-article_id (FK)
-paragraph_id
-content

user_article_sentences
---------------
-user_id (FK)
-article_id (FK)
-article_sentence_id (FK)
-user_content

我看到的一个问题是 article_sentence ID 的变化。如果管理员移动一篇文章，如果我们希望文章内容以正确的顺序排列，则 ID 将需要随着段落 ID 的变化而变化。为了解决这个问题，也许我们可以添加一个 article_sentence_order 列？这样 id 永远不会改变，但内容的顺序由 article_sentence_order 列决定。

合并和删除呢？这些也会导致一些问题，因为不同 ID 的碎片将开始发生。

关于有助于解决这些问题的新架构设计的任何想法？ Google Docs 之类的应用如何处理此类问题？

编辑：

解决移动不同句子的问题。我们可以使用一个名为 order_id 的新列，它可以是 varchar 或 int。一些权衡：如果是 int，那么我将不得不将后续句子的 order_id 增加为自身的加 1。如果使用 varchar，如果我想在 3 和 4 之间插入，order_id 可以简单地类似于“3a”。问题是在我的应用程序代码中，使用数字索引遍历下一个和上一个句子会有点一个问题。

还有其他选择吗？

【问题讨论】：

标签： mysql database database-design relational-database

【解决方案1】：

如果只保存完整版本的内容，每条记录都有一个版本号，这样您就可以了解文章编辑和修改者的完整历史记录？

User:

 - id
 - name 

User_article:

 - id
 - user_id (fk on user, this is the current editor)
 - article_id
 - version_number
 - article_content (the full content of the article)

Article:

 - id
 - created_date
 - user_id (the creator, or main owner )
 - category_id

这样，很容易将文章内容恢复到历史上的前一点，查看哪个用户做了什么修改等

【讨论】：