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