數據庫外交關係

Question

我正在開發一個定製和特定CMS的項目。在前端，許多字段都會有預先填充的選項。但是對於這些字段，需要有一個「其他」選項，允許用戶輸入文本字符串。項目範圍不希望將這些新的「其他」值添加到預填充列表中（現在或將來）。這只是一個例外。項目範圍堅持貫穿整個應用程序的這種靈活性。

我有包含所有這些預填充列表的數據庫表。我把這些表稱爲列表表格（全部以「list_」開頭）

我的問題是關於存儲用戶所做的選擇。如果不是這種靈活性，我會將該值作爲外鍵存儲到適當的列表中。但是，這些字段存儲值（字符串）而不是鍵是有意義的。缺點是索引（次要），內容控制（次要），全局更新，即更改列表中的值不會通過系統翻轉，除非編碼爲（相當大的問題）。我還會提到將數據存儲爲值而不是鍵會使得編程和函數更簡單（我正在編寫一個服務層，它減少了連接並允許函數更通用）。

存儲爲值（字符串）不是關鍵是團隊想要去的路線。

我這樣做會犯很大的錯誤嗎？或者這是相當普遍的？還有其他問題需要考慮嗎？

替代品： 我的替代方法是將「其他」字符串作爲列表中的新行添加，並使用字段使其「隱藏」。

Answer 1

通常，如果您可以存儲外鍵而不是值，那麼它購買的強制一致性通常會使事情在未來更簡單。

但是，「要求」使得它聽起來好像這不是一個選項，這使得它感覺好像數據中存在不一致。聽起來目標是在一個字段中存儲兩種類型的數據：預先定義的值或用戶選擇的值，並且這兩個值具有不同的含義。在不瞭解系統的情況下，很難確定，但這可能會使某些類型的查詢更難以編寫（但並非不可能）。

如果該值確實只是一個文本值，並且預先填充的列表提供了一種簡單的方法來進行選擇，那麼存儲文本值似乎沒問題。但是，這個問題聽起來好像正在將查詢表中的值附加到意義上。如果是這樣，那麼存儲外鍵可能會產生更強大的解決方案。但是，如果選擇「其他」，則可能需要將「其他」值（及其關聯的外鍵值）添加到查找表中，並將另一個自由格式文本字段添加到表中以存儲實際文本。

Answer 2

首先，您所描述的方式中「列表」表的概念感覺很模糊。這似乎表明，對這些實體的規範沒有完全理解或審查。您不需要將「列表」實體與非「列表」實體區分開來。

其次，聽起來像你遇到的問題是，當用戶被給予選擇輸入自己的值而不是可能出現在下拉列表中的項目時。在這種情況下，我會有一個特殊的外鍵值代表「自定義」，然後我將顯示一個文本框供用戶輸入自定義值。我會將自定義值存儲在FK值的單獨列中。每當用戶選擇非自定義選擇時，我會將自定義條目清空（理想情況下，這將通過檢查約束強制執行，但MySQL不尊重它們，因此您必須使用觸發器）。通過這種方式，您的CMS可以簡單地首先查看是否存在自定義值，然後是來自FK的值。同時擁有FK和自定義文本列的好處是，您可以輕鬆更改父表格的組成（添加屬性，添加值，調整值等），而不必影響子表格。