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