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

如何解决协作文章编辑器的良好表结构

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

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将需要更改，而paradition_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 \'之类的问题。问题是在我的应用程序代码中，使用数字索引遍历下一个和上一个句子将是有点问题。 还有其他选择吗？     

解决方法

        只保存内容的完整版本，每条记录都有一个版本号，这样您将拥有该文章的完整历史记录以及由谁修改的历史记录？

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

这样，很容易将文章内容还原到历史记录中的先前位置，以查看哪个用户进行了哪些修改等。