[quote]
做資料庫設計的時候，某些表必須有乙個狀態字段.比如角色表，它的狀態為：已禁用、正常等。那是不是要單獨做一張角色狀態表呢？
那麼其他表的中的狀態字段，是不是也要做一張對應的狀態表呢？
即使狀態只有兩個值？
如果這種狀態只有兩個值可以設定乙個欄位為bool型別
如果狀態包括多個值，但這些值不需要總變化，可以考慮用列舉型別
如果狀態包括多個值，且需要經常新增或刪除，可考慮建立乙個新的表，與主表關聯
[/quote]
[url]例如面向過程的設計中，一張申請表很可能被設計成一張物理表；而物件導向設計中，很可能沒有申請表這麼一張物理表，而只有「使用者資料」、「申請流程」、「申請資質」等物件表，所謂的申請物件，是在執行期由這些物件聚合而成的。[/quote]
正確認識資料冗餘
主鍵與外來鍵在多表中的重複出現, 不屬於資料冗餘，這個概念必須清楚，事實上有許多人還不清楚。非鍵字段的重複出現, 才是資料冗餘！而且是一種低階冗餘，即重複性的冗餘。高階冗餘不是欄位的重複出現，而是欄位的派生出現。
〖例4〗：商品中的「單價、數量、金額」三個字段，「金額」就是由「單價」乘以「數量」派生出來的，它就是冗餘，而且是一種高階冗餘。冗餘的目的是為了提高處理速度。只有低階冗餘才會增加資料的不一致性，因為同一資料，可能從不同時間、地點、角色上多次錄入。因此，我們提倡高階冗餘(派生性冗餘)，反對低階冗餘(重複性冗餘)。
資料庫布林型狀態字段互斥性的SQL更新操作
事件a和b的交集 為空，a與b就是互斥 事件，也叫互不相容 事件。也可敘述為 不可能同時發生的事件。如a b為不可能事件 a b 那麼稱事件a與事件b互斥，其含義是 事件a與事件b在任何一次試驗中不會同時發生 在這樣的設計下，違反了第三正規化，應該拆分表為乙個狀態明細的基礎表，乙個選擇了的啟用狀態的...
專案之初的模型設計與status狀態字段
0x01 但做的模型設計往往是設定字段滿足當前的需求，缺乏足夠的經驗，即使為以後的功能預留出位置，也無法考慮周全。比如，剛開始做使用者表，關於刪除使用者的功能，一開始預想的是直接刪除使用者。等到所有功能做完了，這乙個版本結束了，在下乙個版本迭代中，想要給資料庫新增乙個刪除status欄位，刪除的時候...
關於資料庫冗餘字段設計的利與弊
因為近期完全是我負責某專案開發，所以關於資料庫冗餘欄位的設計，有了一些新的見解。其實在資料庫設計方面，對於冗餘欄位的設計，網上也是褒貶不一的。通過資料的查詢，大致有以下兩個方向 1 支援冗餘欄位的設計 引入冗餘欄位的設計，能夠減少表關聯，使用sql查詢的時候執行效率更快，特別是在資料量比較大的情況下...