1

可以說我有2個表:更改外鍵含義。如何處理?

  • SpeciesId
  • SpeciesName

動物

  • 動物編號
  • SpeciesId - 外鍵

如果你給改變SpeciesName最終用戶的能力,這意味着他們可能會影響引用更改的記錄(至少從用戶的角度來看)所有動物的物種。這可能是一個極端的例子,但這種情況通常如何處理?把最終用戶的責任告訴他們在做什麼?如果之前使用過名稱更改,請禁止?

我們正在討論這種情況,我想從其他人那裏獲得輸入。提出的解決方案之一是刪除外鍵(例如,爲動物表中的物種放置文本字段)。這對我來說看起來並不正確,因爲你在什麼時候繪製了使用外鍵的界限?對我來說,似乎更像是一個培訓問題,以確保管理員瞭解他們所做的更改的影響。我知道這是一個開放式的問題,根據情況可能會有所不同,但我只是想得到一些一般性意見。

+2

嗯,其中之一,Species.SpeciesName應該是唯一的,所以你不應該能夠使用已經在使用的名稱。否則,你的問題不是真正的答案 - 因爲你的真實使用案例不是科學已經定義的例子,所以我們很難說出這些名稱變化將會發生什麼樣的頻率,它們會對其餘的架構,或者爲什麼有一個文本列會更好,如果名稱確實發生了變化。 – 2013-05-02 22:19:21

+0

爲了減輕參考表中更改值所帶來的一些痛苦,您可以實施更改跟蹤,以便能夠告訴誰,何時以及如何更改它們並在必要時恢復這些更改。 – peterm 2013-05-02 22:28:02

+2

您使用這種查找表的原因之一是,名稱更改並不痛苦。在您的替代設計中,如果您擁有屬於一個物種的5000只動物,並且您更改了物種的名稱,則必須更新5000行(並且根據索引可能會更多)。當你有外鍵時,反覆重複的代理(SpeciesId)不會改變;只有FK表中名稱的* 1 *副本發生變化。此外,由於大多數名稱可能會超過4個字符,因此您還可以使用SpeciesId在Animal表中節省大量空間。 – 2013-05-02 22:28:03

回答

0

這是您必須製作的設計決定。您需要從業務角度確定哪些更重要。你重視歷史的準確性還是有效地更新信息?

在你的例子中,由於以下原因,我會不太重視歷史。

  1. 只有最近的約定是重要的。假設一個動物從一個屬性移動到另一個屬性,它確實沒有提供任何價值來知道什麼是舊的和現在無效的屬。

  2. 同一物種的所有動物都應該具有相同的物種ID。你可以免費獲得這個免費的外鍵。假設在物種名稱更改之前添加了一隻老虎。然後在物種名稱更改後添加了一隻不同的老虎。兩隻老虎仍屬於同一物種。

  3. 查詢通過ID數據庫會更容易,也比使用一個字符串,更不用說鑽研字符串解析的業務更可靠。您不必擔心字符編碼,大小寫,空格,標點符號等。假設您想要檢索一個或多個物種的所有動物。

0

放在最終用戶的責任,知道他們在做什麼?

需要決定最終用戶能夠更新什麼。如果您的最終用戶是充分了解該物種科學名稱的生物學家,他應該能夠更新這些信息。否則,可能最好是防止用戶修改此列,或者只有當此特定物種有與之相關的任何動物時。

,這就是一個帶出來的解決方案是刪除外鍵

不要那樣做。您將失去加入這些表格信息的能力。想象一下你的桌子上的物種有一個「大陸」的列,表明這個物種是在美洲,非洲,歐洲,亞洲等地被發現的。如果你使用外鍵,你可以提問這樣的問題:「屬於美國的物種?「這是不可能的,如果你刪除外鍵。