銀行存錢悖論探討�。。ㄉ魅�，邏輯混亂，請看完所有樓再回帖以免越弄越亂）

mike79

原帖由 冬瓜頭 于 2010-1-12 11:33 發(fā)表
我從一開始就沒有認為db本身機制有問題。而是對整個系統(tǒng)的溝通流程方面，有潛在的問題，這一點不理解，是否真正存在，如果存在，怎么解決。

從應用分層的角度來講，每個層面都應該做好自己分內(nèi)的事情。各個層面應該提供一個相互一致的視圖。所以前臺終端顯示給操作員的數(shù)據(jù)，就應該是數(shù)據(jù)庫中已經(jīng)提交的數(shù)據(jù)。但不管怎樣，你總不可能避免人為失誤。萬一那個業(yè)務操作員宿酒未醒呢？

mike79

原帖由 冬瓜頭 于 2010-1-12 11:38 發(fā)表
這只是一筆操作，如果是十萬筆，人如何去一一核對呢？這個問題怎么解決

如果是柜臺操作，就由各個柜臺業(yè)務員處理。如果是后臺批處理，強壯的批處理至少應該可以重新跑一遍而不會重復操作。

冬瓜頭

如果需要全靠最終業(yè)務層來判斷數(shù)據(jù)是否丟失的話，這個工作就很枯燥了，是不是存在人也無法探知的潛在數(shù)據(jù)丟失呢，我認為很有可能，一筆記錄丟了可以對一對，如果底層某個數(shù)據(jù)的丟失并沒有通過某種渠道被業(yè)務層感知，或者丟失之后到被感知的時間過長以至于業(yè)務層也無法調(diào)查了，這是否就是死賬形成的原因之一呢？人為因素+系統(tǒng)因素。

mike79

數(shù)據(jù)是否丟失是否一致，當然是要靠業(yè)務層來判斷的。即使你寫了程序自動判斷，也是要依靠業(yè)務規(guī)則的。何況即使IT系統(tǒng)運行正常，數(shù)據(jù)庫7*24沒有崩潰，也可能存在數(shù)據(jù)丟失。如果前臺應用有bug不小心刪除了數(shù)據(jù)呢？如果操作員不小心多打了個0呢？
我不是很明白這個帖子的用意。難道你認為存在一種機制，可以在IT層面避免或者檢測到所有的錯誤，包括業(yè)務層面的錯誤？

lemonlili

在COMMIT時候會寫日志的。如果COMMIT不成功 ，也就不會提示寫入成功。當日志寫完成后，即使數(shù)據(jù)沒有寫回到數(shù)據(jù)文件也沒問題。這個時候DOWN 機，下次開機的時候會根據(jù)日志把這個記錄寫回數(shù)據(jù)文件。

mike79

原帖由 冬瓜頭 于 2010-1-12 11:31 發(fā)表
操作員錄入了客戶信息，提示成功了，回頭一查，沒了

這種前端認為成功，后端最終回滾的情況是不可能出現(xiàn)的。反過來，前端認為操作失敗，而后端實際上操作成功的情況倒是有可能的。這時候就需要操作員判斷是否需要再次執(zhí)行操作。
ps 你了解了數(shù)據(jù)庫中的事務概念，就不會有這種問題了。

cx6445

原帖由 mike79 于 2010-1-12 13:48 發(fā)表

這種前端認為成功，后端最終回滾的情況是不可能出現(xiàn)的。反過來，前端認為操作失敗，而后端實際上操作成功的情況倒是有可能的。這時候就需要操作員判斷是否需要再次執(zhí)行操作。
ps 你了解了數(shù)據(jù)庫中的事務概念 ...

我倒是覺得lz在推銷他的書，相對于售前能對技術了解到這里也差不多了。

冬瓜頭

“這種前端認為成功，后端最終回滾的情況是不可能出現(xiàn)的。反過來，前端認為操作失敗，而后端實際上操作成功的情況倒是有可能的”

那個例子是我說錯了。
這個帖子沒什么用意，就是探討一下，數(shù)據(jù)丟失到底是怎么丟的，應該從哪里入手杜絕。

冬瓜頭

原帖由 cx6445 于 2010-1-12 13:57 發(fā)表


我倒是覺得lz在推銷他的書，相對于售前能對技術了解到這里也差不多了。

你上鉤了么？

mike79

原帖由 cx6445 于 2010-1-12 13:57 發(fā)表


我倒是覺得lz在推銷他的書，相對于售前能對技術了解到這里也差不多了。

LZ就出了一本書吧？難道有新書面世？
ps 我覺得像存儲之類的書，看廠商的資料以及看SCSI規(guī)范應該足夠了。

[ 本帖最后由 mike79 于 2010-1-12 14:23 編輯 ]