帖子版本控制功能如何实现 --- 考考大家

[骄傲青蛙]

================
实例需求
================

假设， 当前我发的这个帖子， 每次编辑后都保存一个副本，
如果， 我对这个帖子编辑了六次， 那么， 系统则对这六次编辑的改动情况记录一下来。

以后， 我可以查看此帖的改动情况， 什么时候更改过， 那些地方改动过，
而且可以选择最适合的版本作为最终的帖子内容。


================
设计思路
================

数据结构
post (pid, content, changed_time, version_number, current_version_number)

实现过程
新发帖， 插入一条记录到post, version_number为1，current_version_number为0,
修改帖， 插入记录操作如上， 但version_number是编辑帖字段数值自增1， 且当前编辑的pid的current_version_number改为1

数据事例
1, text1 change1, yy-mm-dd, 1, 1
2, text1 change2, yy-mm-dd, 2, 1
3, text1 change3, yy-mm-dd, 3, 1
4, text2 change1, yy-mm-dd, 1, 1
5, text3 change1, yy-mm-dd, 1, 0
6, text1 change4, yy-mm-dd, 4, 0
7, text2 change2, yy-mm-dd, 2, 0

数据索取
就读current_version_number为0的记录


================
缺憾
================
就是 content 的内容太多重复。 想请教一下大家应该如何改进这功能 ?

[深圳phper]

我的看法：可以考虑分表，新建表post_edit 用于保存修改后的版本数据，当然插入的时候也需要 插入这这张表。这样来说查询相对会少点。

[骄傲青蛙]

引用 4 楼 nowphp 的回复:

我的看法：可以考虑分表，新建表post_edit 用于保存修改后的版本数据，当然插入的时候也需要 插入这这张表。这样来说查询相对会少点。

开始我也这么想， 但已经有另一种分表设计纳入系统中， 如果再分表， 对查询优化也是不大， 所以放弃这想法。

[骄傲青蛙]

引用 2 楼 xuzuning 的回复:

你描述的这个就是一个 WIKI 系统 当然可以只保存每个版本间的差异（我以前发过一个text_diff函数） 但是这样做会带来读取上的麻烦 比如需要取得中间某个版本时，就需要从头开始逐一按差异构造出各个过渡版本 如果只是担心存储量过大，那么完全可以考虑采用压缩方式存储

你的回复提醒了我， 该功能的确是一个类似wiki的系统， 开始也没想起。 现在， 好好去研究一下。

[xuzuning]

分表保存是最愚蠢的事情了，事倍功半 既然是版本控制，有谁能说最后一个版本就是正式版本呢

[骄傲青蛙]

引用 7 楼 xuzuning 的回复:

分表保存是最愚蠢的事情了，事倍功半 既然是版本控制，有谁能说最后一个版本就是正式版本呢

默认是最后一个版本是正式版， 但用户本身可以查看各版本， 和设定那个版定为正式版， 我的分表， 是指按时间， 数据库记录数去分表， 按不是如四楼那种方式。

[xuzuning]

对于数据的组织，应考虑到：由于算法上的重大改进，而放弃最近的 n 个版本的可能性

[骄傲青蛙]

我曾经考虑过数据切行来保存，但这样开发复杂又提升一个档次，

[梦康]

如果是我，我也只能走楼主的最上面的办法了，我上次做一个用户的会员卡的使用就是这样，因为用户要能查询每个月的使用记录。 楼主模仿SVN的二进制存储拿过来用用试试那样肯定好——！ 我是路过。没什么高见，还是等楼主放答案。

[xuzuning]

你描述的这个就是一个 WIKI 系统 当然可以只保存每个版本间的差异（我以前发过一个text_diff函数） 但是这样做会带来读取上的麻烦 比如需要取得中间某个版本时，就需要从头开始逐一按差异构造出各个过渡版本 如果只是担心存储量过大，那么完全可以考虑采用压缩方式存储

[床上等您]

相对优化下， 可以将内容保存到文件，db保存文件path，这样文件数会比较多，但省了db比较多的空间

[骄傲青蛙]

引用 9 楼 xuzuning 的回复:

对于数据的组织，应考虑到：由于算法上的重大改进，而放弃最近的 n 个版本的可能性

开发分多个阶段， 现在是第一个阶段， 算法改进放在第二阶段， 目前问题可能就是太多冗余数据， 拖累查询效率。

[骄傲青蛙]

引用 10 楼 zhoumengkang 的回复:

如果是我，我也只能走楼主的最上面的办法了，我上次做一个用户的会员卡的使用就是这样，因为用户要能查询每个月的使用记录。 楼主模仿SVN的二进制存储拿过来用用试试那样肯定好——！ 我是路过。没什么高见，还是等楼主放答案。

用svn的方式来做比较精细， 这是放在开发的后期阶段了。 现在是前期对功能模块的定型， 主要对数据的结构设计和组织规范化。

[夏之冰雪]

我现在就在用类似的，链接如下： http://www.oschina.net/p/wiki+web+help 对这个框架，进行了自己需求的改动 当然，数据量大的时候还要做考虑。。。

[ImN1]

偶的算法和数据库都比较弱，旁观了好一阵子，还是忍不住说两句 1.每次改动都全文+差异保留的做法，写入时计算差异N-1次，每次读取时读取N版本，差异可以直接显示（计算近似0次），-->从文求差异 2.每次改动都只全文保留的做法，写入时不计算差异，每次读取时读取N版本，再计算各版本差异计算N-1次，-->从文求差异 3.每次改动只保留初版+差异的做法，写入时计算差异N-1次，每次读取所有版本的差异，全文只读取1次（初版），再计算N-1次得出各版本全文（后推导），-->从差异求文 4.每次改动只保留最后一版+差异的做法，写入时计算差异N-1次，每次读取所有版本的差异，全文只读取1次（最后一版），再计算N-1次得出各版本全文（前推导），-->从差异求文 写入时的差异计算次数是总计，每次写入其实只计算一次（和上一个版本的差异）而已 2～4的读取后计算都跟读取次数有关，读取M次的话，就是M*(N-1)，假如无缓存刷新一次，M就+1了 然后是差异计算的问题 假设差异为100%（也即全文替换，当然这不可能，因为只是“的地得”还是必然存在的），这个跟重写再重读一次也没区别了，但从差异求全文的计算量反而很大 假设差异仅为一字之差，例如发现一个错别字改掉再保存，保存量就很大 IO和CPU的耗费是个平衡，偶个人是一定做“按需读取”的，如果没指定，一定不会自动一次全部读取全部版本，尤其是前推导做法（保留最后一版）计算量大大减少 如果默认最后一版是正式版，我是一定选择方案4的，然后由编辑人选择前面多少个版本再做相应计算 其实还有一种情况：如果不理会差异（就是显示时不计算不高亮显示编辑了什么，由阅读者目测判断），这就不存在差异计算了，当然这种情况也不是这个帖子讨论的问题

[申祷无]

引用 2 楼 xuzuning 的回复:

你描述的这个就是一个 WIKI 系统 当然可以只保存每个版本间的差异（我以前发过一个text_diff函数） 但是这样做会带来读取上的麻烦 比如需要取得中间某个版本时，就需要从头开始逐一按差异构造出各个过渡版本 如果只是担心存储量过大，那么完全可以考虑采用压缩方式存储

压缩是指使用ARCHIVE引擎之类方法么？刚才我试了一下，用ARCHIVE引擎加入多条变化不是很大的记录空间占用提升得真的非常小。

[BeyondQqiang]

看了帖子觉得分表的想法其实可以的，但是LZ貌似是不想用，那么我觉得可以用分表的思想来做成文本文件来存储，通过PID来查询文件夹，然后通过version_number 来查询对应的文件，如果觉得PID太多导致文件夹太多的话那就可以通过用PID对一个数取模，这样文件夹相对少些，一个文件夹里的文件也相对少些。。。。因为我觉得LZ你的这个需求一条记录的版本会上百么？所以这种我觉得还可以吧。。。。。纯个人见解，LZ莫喷

[再看我一眼]

学习了... 存储差异,压缩存储,wiki原理,分表方式,读取方式,性能权衡.... 信息量略大啊