原帖由 冬瓜头 于 2010-1-12 11:33 发表 http://bbs.chinaunix.net/images/common/back.gif
我从一开始就没有认为db本身机制有问题。而是对整个系统的沟通流程方面，有潜在的问题，这一点不理解，是否真正存在，如果存在，怎么解决。
从应用分层的角度来讲，每个层面都应该做好自己分内的事情。各个层面应该提供一个相互一致的视图。所以前台终端显示给操作员的数据，就应该是数据库中已经提交的数据。但不管怎样，你总不可能避免人为失误。万一那个业务操作员宿酒未醒呢？
原帖由 冬瓜头 于 2010-1-12 11:38 发表 http://bbs.chinaunix.net/images/common/back.gif
这只是一笔操作，如果是十万笔，人如何去一一核对呢？这个问题怎么解决
如果是柜台操作，就由各个柜台业务员处理。如果是后台批处理，强壮的批处理至少应该可以重新跑一遍而不会重复操作。
如果需要全靠最终业务层来判断数据是否丢失的话，这个工作就很枯燥了，是不是存在人也无法探知的潜在数据丢失呢，我认为很有可能，一笔记录丢了可以对一对，如果底层某个数据的丢失并没有通过某种渠道被业务层感知，或者丢失之后到被感知的时间过长以至于业务层也无法调查了，这是否就是死账形成的原因之一呢？人为因素+系统因素。
数据是否丢失是否一致，当然是要靠业务层来判断的。即使你写了程序自动判断，也是要依靠业务规则的。何况即使IT系统运行正常，数据库7*24没有崩溃，也可能存在数据丢失。如果前台应用有bug不小心删除了数据呢？如果操作员不小心多打了个0呢？
我不是很明白这个帖子的用意。难道你认为存在一种机制，可以在IT层面避免或者检测到所有的错误，包括业务层面的错误？
在COMMIT时候会写日志的。如果COMMIT不成功 ，也就不会提示写入成功。当日志写完成后，即使数据没有写回到数据文件也没问题。这个时候DOWN 机，下次开机的时候会根据日志把这个记录写回数据文件。
原帖由 冬瓜头 于 2010-1-12 11:31 发表 http://bbs.chinaunix.net/images/common/back.gif
操作员录入了客户信息，提示成功了，回头一查，没了
这种前端认为成功，后端最终回滚的情况是不可能出现的。反过来，前端认为操作失败，而后端实际上操作成功的情况倒是有可能的。这时候就需要操作员判断是否需要再次执行操作。
ps 你了解了数据库中的事务概念，就不会有这种问题了。
原帖由 mike79 于 2010-1-12 13:48 发表 http://bbs.chinaunix.net/images/common/back.gif
这种前端认为成功，后端最终回滚的情况是不可能出现的。反过来，前端认为操作失败，而后端实际上操作成功的情况倒是有可能的。这时候就需要操作员判断是否需要再次执行操作。
ps 你了解了数据库中的事务概念 ...
我倒是觉得lz在推销他的书，相对于售前能对技术了解到这里也差不多了。
“这种前端认为成功，后端最终回滚的情况是不可能出现的。反过来，前端认为操作失败，而后端实际上操作成功的情况倒是有可能的”
那个例子是我说错了。
这个帖子没什么用意，就是探讨一下，数据丢失到底是怎么丢的，应该从哪里入手杜绝。
原帖由 cx6445 于 2010-1-12 13:57 发表 http://bbs.chinaunix.net/images/common/back.gif
我倒是觉得lz在推销他的书，相对于售前能对技术了解到这里也差不多了。
你上钩了么？:mrgreen:
原帖由 cx6445 于 2010-1-12 13:57 发表 http://bbs.chinaunix.net/images/common/back.gif
我倒是觉得lz在推销他的书，相对于售前能对技术了解到这里也差不多了。
LZ就出了一本书吧？难道有新书面世？
ps 我觉得像存储之类的书，看厂商的资料以及看SCSI规范应该足够了。
[ 本帖最后由 mike79 于 2010-1-12 14:23 编辑 ]