建模是數據庫中的屬性

Question

我有一個相當常見的情況，用戶可以從一組屬性中進行選擇。用戶界面中的屬性由複選框表示。

例如：

組件：硬盤（Y/N），CPU（Y/N），監視器（Y/N），鍵盤（Y/N），等....

在過去，我已經爲藍本，這種情況下是這樣的：

"PCs" 1:M "PC Components" M:1 "Components" 

另一種方法是使「屬性」爲Y/N字段中的「電腦」表。

例如

PCs (table) 
----------- 
PCId(PK) 
Harddrive(y/n) 
CPU(y/n) 
etc... 

在過去，我的理論基於用戶是否可以輸入新的屬性。如果答案是肯定的，那麼我會選擇第一個選項，如果答案是否定的，那麼我通常會使用y/n屬性。

但是現在我有一個場景，其中有大約20個屬性分爲多個類別。在創建ERD之後，它看起來「錯誤」，並且該表具有荒謬的列數。

我的問題是，有沒有一個標準/正確的方式來建模？如果是這樣，它是否有名字？

Answer 1

因爲這些屬性具有兼容的數據類型（它們都是y/n），所以我們很想設計一個更「緊湊」的數據模型（每個屬性不是列）。

如果每個屬性具有不同的數據類型，例如，如果它們被限制爲使用不同查找表的一組值，那麼您必須使用每個屬性的列來理所當然。

請參閱Domain-Key Normal Form。將您的y/n屬性建模爲行意味着您無法表示強制屬性（您必須爲必須具有Y或N值）。所以你有一些約束，N個屬性必須有N行。對最小行數的約束既不是域約束也不是關鍵約束，因此它不能通過DKNF測試。

沒有必要每個表都必須符合DKNF，但如果您問什麼術語描述每個屬性的列設計，我建議「域/關鍵範式」適合。

Answer 2

我遵循這個簡單的規則：每列有一段數據。讓數據庫優化存儲結構。因此，在SQL Server的世界裏，我使用BIT數據類型來做到這一點，而且是分開的列。其他數據庫，我敢肯定，有一個相應的類型。