數據庫中主鍵和外鍵的設計原則[轉]

 

主鍵和外鍵是把多個表組織爲一個有效的關係數據庫的粘合劑。主鍵和外鍵的設計對物理數據庫的性能和可用性都有着決定性的影響。

必須將數據庫模式從理論上的邏輯設計轉換爲實際的物理設計。而主鍵和外鍵的結構是這個設計過程的癥結所在。一旦將所設計的數據庫用於了生產環境，就很難對這些鍵進行修改，因此在開發階段就設計好主鍵和外鍵就是很是必要和值得的。

主鍵：

  關係數據庫依賴於主鍵---它是數據庫物理模式的基石。主鍵在物理層面上只有兩個用途：

        1. 唯一地標識一行。

 

        2. 做爲一個能夠被外鍵有效引用的對象。 http://www.mscto.com

  基於以上這兩個用途，下面給出了我在設計物理層面的主鍵時所遵循的一些原則：

 

        1. 主鍵應當是對用戶沒有意義的。若是用戶看到了一個表示多對多關係的鏈接表中的數據，並抱怨它沒有什麼用處，那就證實它的主鍵設計地很好。

        2. 主鍵應該是單列的，以便提升鏈接和篩選操做的效率。

軟件開發網

 

       注：使用複合鍵的人一般有兩個理由爲本身開脫，而這兩個理由都是錯誤的。其一是主鍵應當具備實際意義，然而，讓主鍵具備意義只不過是給人爲地破壞數據庫提供了方便。其二是利用這種方法能夠在描述多對多關係的鏈接表中使用兩個外部鍵來做爲主鍵，我也反對這種作法，理由是：複合主鍵經常致使不良的外鍵，即當鏈接表成爲另外一個從表的主表，而依據上面的第二種方法成爲這個表主鍵的一部分，然，這個表又有可能再成爲其它從表的主表，其主鍵又有可能成了其它從表主鍵的一部分，如此傳遞下去，越靠後的從表，其主鍵將會包含越多的列了。

 

        3. 永遠也不要更新主鍵。實際上，由於主鍵除了唯一地標識一行以外，再沒有其餘的用途了，因此也就沒有理由去對它更新。若是主鍵須要更新，則說明主鍵應對用戶無心義的原則被違反了。

        注：這項原則對於那些常常須要在數據轉換或多數據庫合併時進行數據整理的數據並不適用。

        4. 主鍵不該包含動態變化的數據，如時間戳、建立時間列、修改時間列等。

        5. 主鍵應當有計算機自動生成。若是由人來對主鍵的建立進行干預，就會使它帶有除了唯一標識一行之外的意義。一旦越過這個界限，就可能產生認爲修改主鍵的動機，這樣，這種系統用來連接記錄行、管理記錄行的關鍵手段就會落入不瞭解數據庫設計的人的手中。

我認爲主鍵能夠分爲兩種，一種是無心義的主鍵，例如News表中的NewsID主鍵，目的只是爲了惟一標識一條記錄，若是數據表中去掉這個主鍵字段，該表中的信息也是完整的，也就是說該字段對用戶是透明的，用戶理不理解都無所謂;一種是有意義的主鍵，好比Orders表中的OrderNO主鍵，這個表是離不開OrderNO這個字段的，這個字段已經成爲業務實體的一部分了，這在作系統分析的時候就已經肯定了，它對用戶來講是可理解的，甚至是須要記憶的。 　　有意義的主鍵是須要本身寫程序或者創建專門的數據表來生成的，並且生成的規則也是在系統分析的時候就肯定好的;對於無心義的主鍵則根本沒有這個必要，下面我列出了一個流程步驟來講明怎樣給數據表分配一個主鍵： 　　一、數據表必定要有主鍵，該主鍵能夠是一個或者多個呵呵，廢話一句 　　二、數據表的主鍵選擇首先在該數據表自有的字段中找，依據是該字段或者字段組合能夠惟一的標識一條記錄，好像也是廢話 　　三、若是在自有字段中實在找不到能夠惟一標識一條記錄的字段或者字段組合(例如News表)時，須要給表增長一個主鍵字段，這個增長的主鍵是無心義的。 　　四、若是找到一個字段能夠惟一的標識一條記錄，則該表的主鍵則爲這個字段(例如Orders表)，這個主鍵就是有意義的 　　五、若是找到一個字段組合能夠惟一的標識一條記錄，則分爲如下兩種狀況 　　六、若是該數據表不須要與其餘的表進行數據主-外鍵關聯，則該表的主鍵則爲這個字段組合，這個字段組合的主鍵也是有意義的 　　七、若是該數據表表須要與其它表產生主-外鍵關聯，這時候也要增長一個主鍵字段，而把找到的那個字段組合做成惟一索引，緣由是多字段主鍵無法與其它表創建數據關聯，這個增長的主鍵是無心義的。 　　八、無心義的主鍵類型在自增的int與guid中選擇，選擇的依據是是否該數據如今或者之後須要進行表分佈，須要分佈就選擇guid，不然就選擇自增int，緣由是自增的int無法進行表分佈