資料庫面對不同商務邏輯約束條件的選擇

標籤：資料庫   約束   商務程序   外鍵   unique   

資料表的約束我覺得還是很有用的，至少在資料庫最佳化方面還是用的比較多的，可以大大的提高檢索效率，作用也是比較明顯的，另外一點，表的約束可以在某種程度上簡化程式碼端的商務邏輯量，這寄存於DBMS上面，其維護性我絕得韓式比較高的，這一般類型的資料庫裡面，我們常見的約束有：主鍵，外鍵，為空白，唯一等，這四類是比較常見的約束，我絕對約束的實質應該是為真實的商務邏輯而服務的，否則則沒有意義，所以，面對不同的商務邏輯逐一的進行分析：
1:什麼情況下使用主鍵：
主鍵的含義是唯一且不為空白，所以根據這個規範，能夠滿足的商務邏輯有很多的，列如我們常見的ID值，必須存在而且不存在為空白的情況，一般來說一個表的會有一個主鍵，至少方面以後的操作，因為無論無論dql語句還是dml語句都得需要唯一不為空白的標識符當做索引值，而且，無特殊的邏輯要求，會要求主鍵自增張：auto_increment;這樣也是符合一般的邏輯要求的，還可以提高檢索速度。
2：什麼情況下使用外鍵：
表的外鍵其實就是主表對於本表的一個約束，說白了就是就是在外鍵欄位要求的範圍內，表示的是一個主從關係，例如部門表和員工表的關係。部門表是一個主表，有一個主索引值，那麼如果員工表想要和主表建立主從關係就要建立一個外鍵，這裡必須明白一個地方，什麼所謂的建立外鍵都在建立在從表裡面的，主表和普通的操作沒有任何區別，在從表建立的外鍵就是一個指定主表主鍵的關係，這樣的話就構成了一個約束關係，比如說一個員工屬於哪一個部門的關係這樣距可以確立了，當然還要注意的是，外鍵不一定是指向主表的主鍵，還可能是unique值，就是外鍵唯一，當然符合商務邏輯，還有外索引值也是可以為空白的，至於這要一開始我也是不理解的，既然建立了外鍵確立了約束條件那為什麼還可以為空白，但是我又結合實際的商務邏輯想一下，如果一個新員工沒有確定部門但需要加入資料庫那怎麼辦，所以外鍵為空白值就符合一般的商務邏輯了。
3：什麼情況下使用不為空白not null
這個的意思就非常的好理解了，就不多做介紹，但是商務邏輯還是有必要說一下，以前這個約束條件我用的就不是很合理，不管什麼我都是不為空白，雖然效率高了，但是這是非常的不科學的，比如所一個註冊表會有很多資訊，什麼為空白什麼不為空白都得要根據實際的商務邏輯想一下，需要這麼想一下，首先應該要根據業務需求來選擇，如使用者名稱，密碼，郵箱，年齡，生日，社會安全號碼這幾個註冊表欄位資訊，首先使用者名稱，密碼，郵箱（一般來說登入或者找回密碼用到）是必不可少的，所以是一定不可為空的，而年齡和生日在一般的無特殊需求的情況下是可以不填寫的，如果設定了不為空白，那麼非得強迫使用者填寫嗎，還有就是社會安全號碼碼，這個其實不太恰當，社會安全號碼作為使用者比較隱私的東西，如果說網站需必須要要身份號這樣資訊時可以不為空白，反之可以為空白，預設即可。
4：什麼情況下使用unique：
這個約束的意義是唯一但可以為空白，為空白是和主鍵唯一的區別，這個約束相對來說還是比較有用的，如部門的名字，當然是唯一的，但是有的新部門沒有名字也是可以為空白的，但是有的時候肯定會有這樣的需求，一個表想要多個主鍵，這是可以用unique結合not null代替一下，畢竟unique可以用多個的，然而如果你還想為唯一性指明條件的話也是可以的，這也是允許的。

綜上總結：所有的約束條件的建立都應該根據業務實際需求而建立

著作權聲明：本文為博主原創文章，未經博主允許不得轉載。

資料庫面對不同商務邏輯約束條件的選擇