在日照場景中依賴db事務回滾

Question

在我目前正在維護的金融系統中，我們依靠數據庫的回滾機制來模擬運行一些大批量作業的結果 - 回滾事務或在結束，取決於我們是否正在進行測試運行。

我真的不能決定我的意見是什麼。在某種程度上，我認爲這很好，因爲那時模擬和實況運行沒有什麼區別 - 另一方面，它只是感覺很噁心，取決於拋出異常來執行業務邏輯的代碼。

對於依靠數據庫事務來執行業務邏輯，您有何看法？

例

請考慮在數據庫中1000個按揭契約的管理系統。現在，用戶想要運行一項批量作業，該批作業使用一些高級搜索條件來確定要開具哪些契據，從而爲每個契據創建下一個期限發票。

她實際上在此之前，她做了試運行（通過執行actualy運行，但在一個事務回滾結束實施），建立在其上的事蹟將開具發票的報告。如果看起來令人滿意，她可以選擇執行實際運行，這將以事務提交結束。

每張發票都會加上一個批號，以便我們稍後在需要時恢復更改，因此批次運行並不「危險」。用戶只是覺得首先能夠模擬結果是更好的UX。

澄清

這是不是測試。我們確實有測試和分期環境。這是關於使用我們的系統的普通用戶想要模擬大型操作的結果，即使不是「無法控制」或「不可逆轉」，也可能看起來「不可控制」或「不可逆轉」。

結論

似乎並不像其他人有對我們的解決方案真正好的理由。與往常一樣，上下文意味着一切，因此在超出性能要求的複雜功能需求的情況下，使用數據庫回滾來實現批量作業模擬似乎是一個可行的解決方案。

由於這個問題沒有真正的答案，所以我沒有選擇一個答案 - 而是我提出了實際提出論點的那些人。

Answer 1

我認爲這是一個可以接受的方法，只要它不與常規處理干擾。

另一種方法是構建一個顯示審查結果的查詢，但我們都有過採取這樣一種方法的經驗，並沒有完全正確地做到這一點;或者發現上下文在查詢和執行之間改變。

在1000行的範圍內，系統負載不太可能是負擔。

Answer 2

一般來說，你應該把你的邏輯分解成更小的可測試塊。

如果有人忘記在「測試模式」下運行，會發生什麼？這聽起來對我來說是一個嚴重的風險。

Answer 3

我不確定你到底在問什麼。以你從字面上

你對依靠 數據庫事務開展 你的業務邏輯的看法？

那麼，這就是爲什麼我們有交易。我們確實依靠他們。我們遇到了錯誤並中止了一個事務，並依靠在該事務範圍內完成的工作進行回滾。因此，利用我們系統的交易行爲是一件好事，如果我們不這樣做，我們需要自己手動滾動相同的東西。

不過我覺得你的問題是關於在現場系統測試，並依託，以做到不損壞不commiting。在理想的世界中，我們有一個實時系統和一個測試系統，我們不會混淆實時系統。這種理想很少見到。更常見的是「修補現場系統，測試？你的意思是測試？」所以實際上你比一些人在比賽中領先。

另一種選擇是在直播系統虛擬數據，讓一些動作可以通過實際運行的所有道路。再次，容易出錯。

系統停運的比例高得驚人是由於手指的麻煩，這是人類誰犯規了。

Answer 4

它的工作原理 - 就像你說的那樣。我擔心繫統的併發性，因爲事務將保存鎖，可能有很多鎖。這意味着您的測試會阻止系統上的任何實際操作（並且任何實時操作操作都會阻止您的測試）。使用測試系統進行測試通常會更好。我不太喜歡它，但是如果運行測試但忘記回滾的風險不是問題，干擾也不是問題，那麼它是實現'假設'類型計算的有效方法。但還不是很乾淨。

Answer 5

在她真正做到這一點之前，她做了一個測試運行（通過執行實際運行實現，但以事務回滾結束），創建一份關於哪些事項將被開具發票的報告。如果看起來令人滿意，她可以選擇執行實際運行，這將以事務提交結束。

這是錯誤的，容易失敗，並且必須在你的數據庫日誌上下地獄。除非你在一次交易中包裝仿真和實際運行（根據檢查1000次行爲所需的時間表來判斷，這將導致很多被阻止的用戶），否則測試運行和實際運行之間不存在保證的一致性。如果有人改變了數據，添加了行等，那麼最終可能會得到一個不同的結果 - 擊敗測試運行的整個目的。

一個更好的方式做這將是測試運行標記的記錄，以及實際運行拿起標籤的記錄和處理它們。或者，如果您有一個胖客戶端應用程序，則可以將記錄提交給客戶端，顯示報告，並且 - 如果獲得批准 - 將其推回。

Answer 6

我們可以看到用戶需要做什麼，相當合理的事情。我的意思是我們第一次正確使用正則表達式的頻率？提煉查詢，直到它完全符合你的要求並不罕見。

不捕捉錯誤的業務後果可能會很高，所以做試運行是有道理的。

鑑於一張白紙，我相信我們可以設計在系統的正式行爲，而不是這個有點後門appraoch表達的簡潔的實現。

現在我需要付出多少努力來解決這個問題？取決於目前的方法是否真的受到傷害。我們可以想象，在一個重用的系統中，它可能導致數據庫中的爭用。

Answer 7

當我在這是「金融體系」的一部分，一個公司工作，曾經有決定使用生產環境，以測試他們的轉換過程（和公正的回滾，而不是在年底提交）項目團隊。

他們差點被槍殺了。事後纔想到，可惜他們沒有。

您聲稱擁有的測試環境適合IT人員使用。獲得類似的「PRO-FORMA」環境，您可以向其保證您的用戶完全可以使用它們。

當我在該銀行工作時，創建這樣一個PRO-FORMA環境是每年關閉的標準程序。

Answer 8

「但這不是關於測試，而是關於想要模擬大型工作結果的用戶。」

解釋：「這不是測試，而是關於模擬」。

有時候我希望Fabian Pascal還在營業。

（哦，萬一有人不理解：這兩個是關於「不永存的結果」）

Answer 9

我在那家銀行工作的PRO FORMA環境中寫的東西也完全是用戶的東西。