作者簡介：
frank sommers is president of autospaces. he also is a senior editor with artima developer.
概述
關於資料管理，有乙個很重要的趨勢，特別是在web應用上，人們樂於使用弱sql模式 — 或者是完全避免忽略關係資料的一些基本原則。在artima最近乙個討論是關於「nosql」運動的，跟以前一樣 — 通常的討論結果基本認為資料庫關係約束很有用處，開發者需要自己去承擔不使用約束帶來的後果。
很多的關於nosql的討論都是圍繞著反資料庫標準的問題 — 弱化sql規範會導致髒資料的產生 — 現代資料管理制度，比如這個sql標準，提供了很多額外的機制去確保資料的完整性。在細讀了最新版的 joe celko's sql for smarties — 被高度推薦的一本書 — 它讓我明白應該用最少的sql功能來保證資料的完整性。例如，我建表時從來不用sql檢查機制，我也不使用其它的標準sql工具，為的就是讓資料庫更加乾淨。
儘管我很相信盡量使用資料管理系統的諸多好處，我還是傾向於在domain和controller層的**裡實現資料完整性相關的操作。當然，所有的**都需要認真的測試。最近我統計了為數不少的我用 scalatest 寫成的測試套件，大概有上百個測試用例，我發現有不低於30%的測試用例會要求在應用層強制檢查資料完整約束。舉個例子，測試用例會檢查 api-level 的前提條件 — 比如，檢查null值是否被正確的處理。如果乙個複雜的物件被當作乙個方法的引數，我會寫**測試這個方法能否在這個複雜物件引數狀態異常時正常處理。
我一直這樣做，即使是在實體層使用了 hibernate validator 、認真的宣告了 entity classes 裡需要校驗的約束條件。最後，我們好要認真的在表現層 — 對於我，這裡是flex — 寫大量的資料完整性檢查**去確保使用者提交有效的資料到server端api裡。表現層的**也有測試用例。總之，由於此，我們在實體層、表現層、資料層編碼來確保資料完整性，同時在測試用例裡相當的一部分都用在覆蓋對控制層、表現層的完整性檢查。
我想，在乙個較為理想的方案裡，資料庫應該對資料有保護作用，包括強制約束。這種效果我們也可以通過寫大量的sql來實現，但這不會是個很合適的方法，因為大多數的sql資料庫都依賴於sql錯誤碼來指示約束異常。例如，設定乙個約束，salsry 字段不能接受小於5000或者大於100000的資料，當使用者試圖插入乙個100的薪水值時資料庫會返回乙個錯誤碼 — 但這個錯誤碼很難被轉換成應用中其它層中可以使用的資訊。我們不去這樣做是因為這樣做的價值很小，特別是這種轉換在不同的資料庫之間還不能相容。
你認為什麼地方是最合適的定義資料約束的地方呢？你是否同意sql應該提供更多的標準錯誤碼來提示資料違法約束條件呢？
資料庫中正規化的分類和它們之間的轉化
資料庫的設計正規化是資料庫設計所需要滿足的規範，滿足這些規範的資料庫是簡潔的 結構明晰的，同時，不會發生插入 insert 刪除 delete 和更新 update 操作異常。反之則是亂七八糟，不僅給資料庫的程式設計人員製造麻煩，而且面目可憎，可能儲存了 大量不需要的冗餘資訊。設計正規化是不是很難懂...
微服務？資料庫？它們之間到底是啥關係？
過去幾年來，微服務架構 這個術語持續火熱，它描述了一種將軟體應用程式設計為可獨立部署的服務套件的特定方式。儘管這種架構風格沒有確切的定義，但圍繞業務能力，自動化部署，網點智慧型以及語言和資料的分散控制等方面存在著某些共同特徵。簡而言之，微服務架構是一種將單應用程式作為一套小型服務開發的方法，每種應用...
B樹，B 樹，以及它們和資料庫索引之間的關係
學習b樹和b 樹，需要從以下幾方面來理解，直接上來整定義，很難懂。知識點如下 1.磁碟結構 2.資料如何在磁碟中儲存 3.什麼是索引 4.什麼是多級索引 5.m way搜尋樹 二叉搜尋樹bst的推廣 6.b樹 7.b樹的插入和刪除 8.b 樹 一 磁碟結構 磁碟 硬碟 中儲存介質是圓形的,類似光碟。...