2017-05-03 77 views
0

我做了一個數據庫系統就在這裏:同時訪問數據庫;保持數據一致在所有連接

(在規範化的意見是高度讚賞,以及 - 我中有你會恨我什麼我tblIsolateSensitivity做了的感覺;只有tblHAIFile有一堆布爾字段和外鍵)。

比方說,我們有x個終端訪問數據庫。 X1編輯患者01,X2編輯患者02,X3同時刪除患者01。我如何確保三個終端之間的數據都是最新且一致的?

此刻,我只在查詢需要完成時才查詢數據(即:當用戶搜索記錄時,或者如果程序需要根據數據庫記錄驗證某些內容),這意味着數據僅與用戶最近的查詢一樣更新。這使得很難確保所有終端上的數據都是最新的。當然,對於刪除的條目,我有錯誤處理來處理,但其餘的,以及...

所以,我的問題是:你們通常如何處理這種情況?是否有這個概念的名稱,以便我可以查找並閱讀很長時間?

回答

2

從數據庫設計的角度來看,你應該樂觀併發悲觀併發閱讀起來。這兩個選項可以確保您沒有兩個用戶同時修改相同的記錄,或者至少如果您允許,可以檢測到衝突以便解決衝突。

樂觀併發背後的基本思想是允許多個用戶同時查看和修改數據,假設這將是比較罕見的。但是,在任何用戶寫入數據更改之前,都會進行檢查以確保基礎數據自最初讀取以來未發生更改。在某些情況下,您可以使用update之前的read手動執行此操作,並根據緩存的值檢查每個列的值。但是,這很麻煩。某些DBMS系統具有使這更簡單的功能。例如,SQL Server具有ROWVERSION(前身爲TIMESTAMP)數據類型,它可以讓別人是否因爲你讀它最後一次變更記錄您檢查容易使用單個值。

背後悲觀併發的基本想法是,你在你要改變它期望把鎖的記錄。當您持有鎖時,DBMS將阻止其他人獲得自己的鎖。

樂觀併發的優勢在於它重量輕,不會對應用程序造成太大幹擾,讓我們在極少數情況下手動(或自動)解決衝突。你也不必擔心有人讀過一個記錄,鎖定它,然後回家過週末。

悲觀併發的好處是,它可以防止碰撞,但它可以從工作停止一個用戶,而他們等待另一個完成他們在做什麼。

從當記錄的背景改變(即它們是由另一個用戶改變)通知用戶的角度來看這不是一個數據庫設計功能。它可能是應用程序邏輯或應用程序數據訪問層的一個功能。

+0

謝謝你這麼多詳細的說明!我不得不承認,我正在考慮對數據庫上的記錄進行悲觀併發(不僅僅是因爲我通常是pess-我的意思是現實主義者)。我認爲可能發生的問題是,如果應用程序/數據庫連接崩潰並且記錄被鎖定,直到DBA解鎖所述記錄。 –

+0

@RemiDarren你的評論的最後一句話是沒有問題的。任何嚴重的數據庫系統(如Postgres,MS SQL Server,Oracle等)都會自動釋放任何正常關閉或悲劇失敗的連接所持有的鎖。同樣,由該關閉/失敗連接進行的任何事務都將回滾。這些是數據庫服務器的一些基本職責。 –

+0

@RemiDarren請參閱:[悲觀鎖定和客戶死亡](https://dba.stackexchange.com/q/37225/19079) –