經過多年的企業級相關開發，跟資料庫的交道打得太多了。每個企業相關的專案都離不開資料庫，尤其是mis，erp和一些報表等需要儲存相關的，資料庫是不二選擇了。 從剛開始的拖拽控制項，到慢慢學著封裝，走了很長的路。越到後來，越是如履薄冰，因為跟資料庫的耦合太緊，基本意味著設計過於依賴本來是幫助我們的儲存介質。這顯然是個度的把握。對什麼事物過於依賴總不是好事。尤其資料庫跟程式的依賴就是業務邏輯跟資料儲存的依賴。雖然現在的oracle有了自己的form builder， report等直接可以實現業務的工具。 但我認為這不見得是好事。我的看法一直是業務實現最好不要知道資料存在那裡了，存給誰了， 只要知道交給誰去存就可以了。xml的出現應該是個讓人振奮的亮點。當然這個話題是比較大的，我要說的，只是其中相關的一點，很多時候我們可能只需要建立在某一種資料庫之上構造我們的程式，或者某幾種，又或者我們在將來的某個時間發現需要更換其他資料庫來支援系統，又或者使用者說我們必須更換資料庫來適應他們的業務變化。如果們的程式只依賴在某個資料庫上，那麼麻煩就會來臨。尤其是在系統中如果寫 了很多oracle或者access或者其他某種資料庫特有的sql，而沒有採用規範的處理。 下面的一些設計，或許會帶來新的局面，當然應該有更高明的設計，也許不同的領域不同的需要有不同的設計方式。
廢話是需要說的，但是重點不是廢話，下面是一張uml設計圖：
虛線左邊是資料來源管理部分，可以單獨作為乙個單元或者命名空間，只要單獨提供乙個idbmanage給外界（外界即，需要資料庫連線的地方）就可以實現資料庫的讀寫。虛線右邊是提供具體的資料集，tonsquery是乙個抽象的聚合了資料集的資料集類，它可以支配需要的具體資料集來完成資料處理，也可以通過tdb的派生類來完成對不同資料庫型別的特殊sql語句的處理。
資料庫介面隔離設計
經過多年的企業級相關開發，跟資料庫的交道打得太多了。每個企業相關的專案都離不開資料庫，尤其是mis，erp和一些報表等需要儲存相關的，資料庫是不二選擇了。從剛開始的拖拽控制項，到慢慢學著封裝，走了很長的路。越到後來，越是如履薄冰，因為跟資料庫的耦合太緊，基本意味著設計過於依賴本來是幫助我們的儲存介質...
資料庫隔離級別
read uncommited 讀未提交 最低級別，可讀取未提交事物的資料，這會導致髒讀，比如 某時刻會話a修改了乙個資料，但還未提交，此時會話b，讀取了該資料，這是，會話a回滾了事物，這就導致資料出現了不一致狀態，這就是髒讀 read commited 提交讀 避免了髒讀，但會導致不可重複讀，例如...
資料庫隔離級別
資料庫事務的隔離級別有4個，由低到高依次為read uncommitted read committed repeatable read serializable，這四個級別可以逐個解決髒讀 不可重複讀 幻讀這幾類問題。可能出現 不會出現 髒讀 不可重複讀 幻讀read uncommitted re...