2
我認識到在很多情況下，把「無」看起來可能不那麼糟糕。但是，我想在不同的表中使用此特定查找表中的值（數千行），其中包含幾個與可查表的數據直接相關的非空字段。我應該把「無」放入我的查找表嗎？
真實世界的場景：
查找表是仿製藥名的列表，其中包含的代碼從我們的應用程序連接上其他數據庫分開。
我們有一個存儲DrugId，OrderId（FK），頻率，劑量等的處方表，目前這些處方都是不可空的。
在某些情況下，訂單的處方信息是必需的，所以僅僅通過沒有記錄來解決問題（並且沒有其他跟蹤手段）是不夠的 - 我們需要知道爲什麼有沒有處方輸入，並且能夠在日後審查數據時重新填充正確的原因。
一個想法是添加「無」作爲藥物查找表的一部分，其構成了該問題的基礎。我擔心採用這種方法有以下幾個原因：
- 好像在每一個場景，當我們想消費的數據，我們多少還記得考慮到這一點（有一對夫婦除了少數例外，因爲隨着內加入上一個第三方數據庫。）
- 這對於任何進入該項目的人來說都是非常不明顯的（更不用說屁股疼痛了），並且必須進行獨特的測試。也許單獨用「無」這樣做並不是那麼糟糕，但是我們想要在混合中添加「拒絕」還是「不知道」？現在，我們的查找表中有3個非顯而易見的例外，這些數據必須在每次訪問時記錄。
- 我們可以將當前必填字段設置爲空或將僞造數據插入到其中。
其他的想法來解決這個情景是：
添加新列的順序與選項，例如「有規定」，「下降」，「沒有處方。」這是不期望的，因爲成千上萬的行將是'空'，但其他方面看起來不太糟糕。
創建一個新表，僅記錄「例外」情況，例如「無」或「不知道」該字段何時需要。這是目前最吸引我的一個，因爲它產生了非常明顯的例外情況，必須加以解釋。當然，不利之處在於一個新表格（一個零關係），列數很少。這似乎是用於重新填充UI的最簡單的數據形式。
SO社區的想法？
根據達成最終解決方案的有用性選擇最佳答案。我最終將一個代碼（不是外鍵）放入Orders表中，它提供了諸如「無響應」，「存在」，「無」等信息。這最終可以非常輕鬆地使用驗證代碼以及pre填充單選按鈕選項。 – emragins