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

2021-12-30 10:54:20 字數 1478 閱讀 2301

資料表的約束我覺得還是很有用的,至少在資料庫優化方面還是用的比較多的,可以大大的提高檢索效率,作用也是比較明顯的,另外一點,表的約束可以在某種程度上簡化程式**端的業務邏輯量,這寄存於dbms上面,其維護性我絕得韓式比較高的,這一般型別的資料庫裡面,我們常見的約束有:主鍵,外來鍵,為空,唯一等,這四類是比較常見的約束,我絕對約束的實質應該是為真實的業務邏輯而服務的,否則則沒有意義,所以,面對不同的業務邏輯逐一的進行分析:

1:什麼情況下使用主鍵:

主鍵的含義是唯一且不為空,所以根據這個規範,能夠滿足的業務邏輯有很多的,列如我們常見的id值,必須存在而且不存在為空的情況,一般來說乙個表的會有乙個主鍵,至少方面以後的操作,因為無論無論dql語句還是dml語句都得需要唯一不為空的識別符號當做索引值,而且,無特殊的邏輯要求,會要求主鍵自增張:auto_increment;這樣也是符合一般的邏輯要求的,還可以提高檢索速度。

2:什麼情況下使用外來鍵:

表的外來鍵其實就是主表對於本表的乙個約束,說白了就是就是在外鍵欄位要求的範圍內,表示的是乙個主從關係,例如部門表和員工表的關係。部門表是乙個主表,有乙個主鍵值,那麼如果員工表想要和主表建立主從關係就要建立乙個外來鍵,這裡必須明白乙個地方,什麼所謂的建立外來鍵都在建立在從表裡面的,主表和普通的操作沒有任何區別,在從表建立的外來鍵就是乙個指定主表主鍵的關係,這樣的話就構成了乙個約束關係,比如說乙個員工屬於哪乙個部門的關係這樣距可以確立了,當然還要注意的是,外來鍵不一定是指向主表的主鍵,還可能是unique值,就是外來鍵唯一,當然符合業務邏輯,還有外鍵值也是可以為空的,至於這要一開始我也是不理解的,既然建立了外來鍵確立了約束條件那為什麼還可以為空,但是我又結合實際的業務邏輯想一下,如果乙個新員工沒有確定部門但需要加入資料庫那怎麼辦,所以外來鍵為空值就符合一般的業務邏輯了。

3:什麼情況下使用不為空not null

這個的意思就非常的好理解了,就不多做介紹,但是業務邏輯還是有必要說一下,以前這個約束條件我用的就不是很合理,不管什麼我都是不為空,雖然效率高了,但是這是非常的不科學的,比如所乙個登錄檔會有很多資訊,什麼為空什麼不為空都得要根據實際的業務邏輯想一下,需要這麼想一下,首先應該要根據業務需求來選擇,如使用者名稱,密碼,郵箱,年齡,生日,身份證號這幾個登錄檔字段資訊,首先使用者名稱,密碼,郵箱(一般來說登入或者找回密碼用到)是必不可少的,所以是一定不能為空的,而年齡和生日在一般的無特殊需求的情況下是可以不填寫的,如果設定了不為空,那麼非得強迫使用者填寫嗎,還有就是身份證號碼,這個其實不太恰當,身份證號作為使用者比較隱私的東西,如果說**需必須要要身份號這樣資訊時可以不為空,反之可以為空,預設即可。

4:什麼情況下使用unique:

這個約束的意義是唯一但可以為空,為空是和主鍵唯一的區別,這個約束相對來說還是比較有用的,如部門的名字,當然是唯一的,但是有的新部門沒有名字也是可以為空的,但是有的時候肯定會有這樣的需求,乙個表想要多個主鍵,這是可以用unique結合not null代替一下,畢竟unique可以用多個的,然而如果你還想為唯一性指明條件的話也是可以的,這也是允許的。

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

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

資料表的約束我覺得還是很有用的,至少在資料庫優化方面還是用的比較多的,可以大大的提高檢索效率,作用也是比較明顯的,另外一點,表的約束可以在某種程度上簡化程式 端的業務邏輯量,這寄存於dbms上面,其維護性我絕得韓式比較高的,這一般型別的資料庫裡面,我們常見的約束有 主鍵,外來鍵,為空,唯一等,這四類...

01 2資料庫約束條件

約束的分類 1 主鍵 pk primary key 2 唯一約束 uk unique key 3 外來鍵約束 fk foreign key 4 非空約束 nn not null 5 檢查約束 ck check 6 預設值約束 default ps 1 pk uk nn 唯一且非空 2 實現方法 co...

資料庫之約束條件

約束條件 python primary key pk 標識該字段為該錶的主鍵,可以唯一的標識記錄 foreign key fk 標識該字段為該錶的外來鍵 not null 標識該欄位不能為空 unique key uk 標識該字段的值是唯一的 auto increment 標識該字段的值自動增長 整...