主鍵和外鍵是把多個表組織為一個有效的關系資料庫的粘合劑。主鍵和外鍵的設計對實體資料庫的性能和可用性都有着決定性的影響。
必須将資料庫模式從理論上的邏輯設計轉換為實際的實體設計。而主鍵和外鍵的結構是這個設計過程的症結所在。一旦将所設計的資料庫用于了生産環境,就很難對這些鍵進行修改,是以在開發階段就設計好主鍵和外鍵就是非常必要和值得的。
主鍵:
關系資料庫依賴于主鍵---它是資料庫實體模式的基石。主鍵在實體層面上隻有兩個用途:
1. 惟一地辨別一行。
2. 作為一個可以被外鍵有效引用的對象。 http://www.mscto.com
基于以上這兩個用途,下面給出了我在設計實體層面的主鍵時所遵循的一些原則:
1. 主鍵應當是對使用者沒有意義的。如果使用者看到了一個表示多對多關系的連接配接表中的資料,并抱怨它沒有什麼用處,那就證明它的主鍵設計地很好。
2. 主鍵應該是單列的,以便提高連接配接和篩選操作的效率。
軟體開發網
注:使用複合鍵的人通常有兩個理由為自己開脫,而這兩個理由都是錯誤的。其一是主鍵應當具有實際意義,然而,讓主鍵具有意義隻不過是給人為地破壞資料庫提供了友善。其二是利用這種方法可以在描述多對多關系的連接配接表中使用兩個外部鍵來作為主鍵,我也反對這種做法,理由是:複合主鍵常常導緻不良的外鍵,即當連接配接表成為另一個從表的主表,而依據上面的第二種方法成為這個表主鍵的一部分,然,這個表又有可能再成為其它從表的主表,其主鍵又有可能成了其它從表主鍵的一部分,如此傳遞下去,越靠後的從表,其主鍵将會包含越多的列了。
3. 永遠也不要更新主鍵。實際上,因為主鍵除了惟一地辨別一行之外,再沒有其他的用途了,是以也就沒有理由去對它更新。如果主鍵需要更新,則說明主鍵應對使用者無意義的原則被違反了。
注:這項原則對于那些經常需要在資料轉換或多資料庫合并時進行資料整理的資料并不适用。
4. 主鍵不應包含動态變化的資料,如時間戳、建立時間列、修改時間列等。
5. 主鍵應當有計算機自動生成。如果由人來對主鍵的建立進行幹預,就會使它帶有除了惟一辨別一行以外的意義。一旦越過這個界限,就可能産生認為修改主鍵的動機,這樣,這種系統用來連結記錄行、管理記錄行的關鍵手段就會落入不了解資料庫設計的人的手中。
我認為主鍵可以分為兩種,一種是無意義的主鍵,例如news表中的newsid主鍵,目的隻是為了唯一辨別一條記錄,如果資料表中去掉這個主鍵字段,該表中的資訊也是完整的,也就是說該字段對使用者是透明的,使用者理不了解都無所謂;一種是有意義的主鍵,比如orders表中的orderno主鍵,這個表是離不開orderno這個字段的,這個字段已經成為業務實體的一部分了,這在做系統分析的時候就已經确定了,它對使用者來說是可了解的,甚至是需要記憶的。
有意義的主鍵是需要自己寫程式或者建立專門的資料表來生成的,而且生成的規則也是在系統分析的時候就确定好的;對于無意義的主鍵則根本沒有這個必要,下面我列出了一個流程步驟來說明怎樣給資料表配置設定一個主鍵:
1、資料表一定要有主鍵,該主鍵可以是一個或者多個呵呵,廢話一句
2、資料表的主鍵選擇首先在該資料表自有的字段中找,依據是該字段或者字段組合可以唯一的辨別一條記錄,好像也是廢話
3、如果在自有字段中實在找不到可以唯一辨別一條記錄的字段或者字段組合(例如news表)時,需要給表增加一個主鍵字段,這個增加的主鍵是無意義的。
4、如果找到一個字段可以唯一的辨別一條記錄,則該表的主鍵則為這個字段(例如orders表),這個主鍵就是有意義的
5、如果找到一個字段組合可以唯一的辨別一條記錄,則分為以下兩種情況
6、如果該資料表不需要與其他的表進行資料主-外鍵關聯,則該表的主鍵則為這個字段組合,這個字段組合的主鍵也是有意義的
7、如果該資料表表需要與其它表産生主-外鍵關聯,這時候也要增加一個主鍵字段,而把找到的那個字段組合作成唯一索引,原因是多字段主鍵沒法與其它表建立資料關聯,這個增加的主鍵是無意義的。
8、無意義的主鍵類型在自增的int與guid中選擇,選擇的依據是是否該資料現在或者以後需要進行表分布,需要分布就選擇guid,否則就選擇自增int,原因是自增的int沒法進行表分布