數據庫事務時'一致狀態'/'原子性不需要

Question

我試着瞭解何時使用數據庫事務，如果我不需要一致的狀態或「嚴格」原子性。

我沒有一些銀行風格的要求，需要減少一列以抵消其他地方的添加。

我確實有某種形式的原子性，但僅限於'易用性'，我想知道是否足以使用db事務。

具體來說，我需要我的用戶在表A，B和C中創建一個條目。表C依賴於B和B依賴於A.在瀏覽器中，我實際上以一種形式顯示所有數據，並且當用戶提交，它被髮送到後端，試圖在表A中輸入一個條目，然後是B（帶有剛剛從A創建的引用Id），隨後是C（帶有從B創建的引用標識）。

如果A失敗，用戶被reshown與關於A. 如果A成功的錯誤消息的形式，而B失敗，則用戶被重定向到一個頁面中加入乙& C. 如果A &乙成功並且C失敗了，用戶被重定向到一個頁面來添加C.

正如您所看到的，這可能是相當多的錯誤處理和只是說「全部成功」或「某事失敗，沒有任何創建」的事務，將是最簡單的，因爲我可以保持用戶在同一頁面上，或者如果成功則重定向。也請記住在B & C上失敗的可能性是相當低的，因爲我在客戶端驗證...

我的問題是我應該在何時使用事務方法與錯誤處理方法，當我需要原子性並不那麼「嚴格」。在選擇交易方法或一系列插入方法之前，我需要做些什麼？

Answer 1

您應該在「全部或全部」情況下使用事務。 IOW，如果B或C失敗，則保存（插入或更新）到A應該回滾。如果全部都沒有通過，那麼沒有通過，數據庫保持原樣。也就是說，用某些語言進行交易可能很困難。在你的情況下，我可能更喜歡創建一個存儲過程，將所有數據傳遞給該過程。在過程中，我會將這些操作包裝在一個事務中，並讓該過程返回一個合格/不合格指示符，或者創建表A的記錄ID，如果有任何部分失敗，則返回-1。