高手请进！

Question

小弟不明白CrazyFor(蚂蚁)所提到的：为什么数据交叉问题带来了数据库文件方式不可用呢？

Answer 1

但是问题是生成了日志文件我们可以查出我们刚改的日志记录，再写一条Undo命令清除该条日志记录，您看行不行，或者您看有没有更好的方法？

Answer 2

CrazyFor(蚂蚁) 说的没有错。
    如果，仅仅是如果，你的用户要求失效性不是很强，而且数据操作不需要立即返回准确结果的化，可以采用申请方式操作。既
    每一个用户的操作实际上只是对本地脱机数据的操作，得出的结果只是预计结果。实际上，对于服务器来说，只是在那个时间点上的某个客户的一个操作请求。操作请求延时传到。
    你就可以在客户端记录什么客户，什么时间，对某数据提出了什么样的操作请求，保存。
    在一个统一的时候，把所有请求记录执行一次，然后更新每个客户端数据，使其与服务器同步。
上面只是一个想法：）

Answer 3

DJMPH(冷开水)说的好，想法不错。 但数据交叉问题还是没有解决，主要是逻辑上。 和客户端对数据的操作权限，关系很大。 详细描述下，是个有意思的方法。 我可没敢这样做过，太麻烦啦。

Answer 4

假若用户只是做插入新纪录, 不作更新现有纪录, 甚至删除纪录的话, 楼主的方式, 在某特定的环境下, 还是可以的.我们选用sql server, 便是要把'定期上/下传'周期减至最短, 并尽量做到'real time'实时运作.如同是银行的帐户户囗管理是用上述方法, 别有用心的人便可以在'同时', 在全国不同的地方, 对相同的户囗, 提相同的款项, 若银行不是用'实时'的运作, 银行不知道贼人同时在各地一齐提款, 便会容许贼人多次提款了. 因些若是要多人同时实时运作, 上述的方法会有极大的问题发生.

Answer 5

hehe,大家误会我的意思啦，我的意思不是说在客户机上的操作就算数的，是指吧操作汇总道服务器执行，因为先是脱机操作的，所以先前的到的是预计结果，实际的结果应该在服务器安时间排序执行，当然有些能成功，有些就一定要失败的。得到的结果数据覆盖客户端就是了。这样的操作一定不适合银行啊，商店啊什么的。倒是适合库存操作不剧烈的分库房操作。

Answer 6

我认为DJMPH(冷开水)的想法比较切题！
我曾经做过一个金融IC卡的交易模型也是半联机访问型的：）
不过与楼主的问题不同的是金融卡本身就存储了一个公开密钥加密的用户帐号数据，该模型只要求客户端完全安全地保存一个交易日志（可用数据库处理），交易过程就是一个“事务”，使用数据库事务处理机制即可处理该交易过程（注意：并不是用数据库，而是数据库原理），并修改用户金融卡帐号数据（只是支出），相当于是DJMPH(冷开水)的对脱机数据操作和操作请求的存储。
客户端定期不定期地向服务器提交交易日志，此时只需对多个日志数据库进行合并即可，只是需要返回挂失新名单。
这只是我做过的一个模型，不管是否能给楼主一点帮助，重在参与，为了得分吗；）

Answer 7

webstorm(mars)的模型与小弟的模型差不多，谢谢您的帮助！分我会给的，但我还要再等几天，到13号吧，我希望能有多几个模型帮助完成我的模型。
DJMPH(冷开水)我也会一并感谢，因为他给了大家比较大的启发。
CrazyFor(蚂蚁)斑竹最够意思！erickleung()的模型也不错！newdongkui(老乌鸦)所说的能不能再具体一些，为什么比较麻烦？其他人再接再厉我的分虽然不多但我可以保证我会以各种方式给大家加够我认为有所值的分数的！