用戶表和用戶首選項。這是正常化的嗎？

Question

我有一個名爲Users的表，它有一個不斷增長的首選項列表。這些偏好可以包括ReligionId（這將關鍵到另一個包含宗教列表的表）。

偏好列表正在增加。我想將它從Users表中拆分成2個表格。我認爲最好的策略是製作一個名爲UserPreferences的單獨表格。我想知道這樣做是否符合正常化規則。這是一個讓事情變得更清晰的例子。

這是標準化？有更好的方法嗎？所有評論贊賞。

編輯：如何使用UserPreferences鍵切換到其他表：

Answer 1

你至少可以只是用戶和首選項。用戶和偏好之間應該有一對多的關係。一個用戶可以有許多偏好。您也可以將電子郵件地址分成另一個表格 - 這樣一個用戶可以有多個電子郵件地址 - 您可以有一個標誌來表示主要電子郵件地址。該DDL看起來像：

create table Users 
    (
     UserId int, 
     Age int 
    ) 

    create table Preferences 
    (
     PreferencesId int, 
     UserId int, 
     ReligionId int, 
     PersonalDescription varchar(2000), 
     HairColor int 
    ) 

    create table EmailAddresses 
    (
     EmailId int, 
     UserId int, 
     EmailAddress varchar(100), 
     IsPrimary bit 
    ) 

    create table Religion 
    (
     ReligionId int, 
     Name varchar(200) 
    ) 

Insert into Religion (ReligionId, Name) Values (1, 'Jediism') 
Insert into Religion (ReligionId, Name) Values (2, 'Sithism') 
Insert into Religion (ReligionId, Name) Values (3, 'Yuuzhan Vong') 
Insert into Religion (ReligionId, Name) Values (4, 'Pinacism') 

Insert into Users (UserId, Age) Values (1, 30) 
Insert into Users (UserId, Age) Values (2, 18) 

Insert into Preferences (PreferencesId, UserId, ReligionId, PersonalDescription) values (1, 1, 1, 'a description') 
Insert into Preferences (PreferencesId, UserId, ReligionId, PersonalDescription) values (2, 1, 4, 'another description') 
Insert into Preferences (PreferencesId, UserId, ReligionId, PersonalDescription) values (3, 1, 4, 'even another description') 

Answer 2

它沒有意義在拆分單個表兩張表。只有你這樣分裂的時間是某些用戶根本沒有首選項。

創建一個新列 - 無論何時新首選項出現 - 不是一個好主意。

如果你認爲首將在未來的增長，你可以用下面的方法 -

Answer 3

規範化userPreference表將包含用戶ID，preferenceID和preferenceValue。偏好設置會將您的所有偏好設置（電子郵件，年齡等）列在一行中，ID爲ID，以及您希望添加的任何描述性信息。

---

因爲數據類型的偏好值的不同，你可以聲明它作爲一個字符串/ VARCHAR，或者，如果你真的想，有不同的數據類型的不同偏好值，如「prefValInt，」' prefValChar「等，其中只有一列包含一個值。

我通常只使用一個字符串。現在

---

，如果要強制引用完整性，就像在你上面的例子，你又回到了其在不同列中的每個preferenceID，所以你可能會希望讓那些喜好在主表和所有查找表中的其他人。

---

需要RI執行，如religionID和hairColorID任何列，可以去在用戶表中，或者可以在userPreferenceRI表去與用戶表1-1關係。任何沒有強制執行RI的列（例如age，dateOfBirth，accountBalance，emailBody）都可以進入userPreference表，其中PK是用戶ID和preferenceID以及與用戶表的一對多關係。

HTH

---

，你也應該考慮到現有的首選項的可能性。對於必需的字段，例如ageAtPointInTime或dateOfBirth，您應該將它們存儲在用戶表中。對於人口稀少的偏好（大多數人沒有答案），你應該把它們放在查找表中。

user: userID, requiredFld1, requiredFld2 
    preference: preferenceID, preferenceName, preferenceDescription 
    userPreference: userID, preferenceID, userPreferenceVal as varchar(100) 
(list of columns never changes) 
    userPreferenceRelated: userID, religionID, hairColorID, otherPreferenceID 
(list of columns grows over time) 

Answer 4

如果你說你有成長的偏好，那麼我會建議你做的偏好的新表和的Fkey添加到使用UserPreferences

表的用戶 - 用戶ID，電子郵件，年齡，ALTERNATEEMAIL ...

偏好表 - Preferenceid，preference_Value，活性，需要

用戶偏好表 - 用戶標識，preferenceid，preference_data

現在，您可以在首選項表中將不斷增加的首選項列表連接到用戶界面，並且這兩列（活動的和必需的）將幫助您從後端輕鬆控制表單。

而在用戶偏好表中，您只需使用用戶標識引用偏好ID，並存儲用戶爲該偏好輸入的數據。

我希望這很清楚。

Answer 5

一些人建議存儲偏好每行一個。這稱爲實體 - 屬性 - 值表，並且它是而不是歸一化的。有人說EAV是「更規範化」，但他們錯了。沒有規範化的規則鼓勵EAV作爲關係數據庫中的設計。你可以告訴它

一個切實可行的辦法不是標準化的是，你可以不再使用外鍵約束你的宗教查找表，如果所有喜好的所有值在這個喜好表共享一個列。您不能使外鍵約束僅限於特定首選項類型的行上的值--FK約束始終適用於表中的所有行。
基本上，實體屬性值打破了SQL對約束的支持。

唯一標準化設計是定義一個單獨的列爲每個不同的偏好。然後，您可以定義適合該首選項類型的數據類型和約束條件。

如果你真的想了解關係和規範化，閱讀SQL and Relational Theory: How to Write Accurate SQL Code by C. J. Date。

每一列代表從一組選項。一組可以是一組整數，或一組宗教或一組電子郵件地址。表格中的一行是一組「配對」的集合，例如給定的用戶具有姓名，出生日期，宗教信仰和電子郵件地址，因此這些值被一起匹配成一行，並且他們一起描述了世界上存在的東西，即具有這些屬性的人類。

這意味着，在每一行中，您爲每個列選擇一個值，即從每個引用的組件集中選擇一個值。並且每列包含來自一組的值只有。在宗教專欄中，您只能選擇宗教，您也不能將喜歡的顏色和母親的婚前姓名和鞋號放在同一列。

這就是爲什麼EAV從關係角度來看是虛假的，因爲它將來自任何和所有不同屬性的值糅合到同一列中。它更像是電子表格而不是數據庫。我並不是說關係數據是存儲數據的唯一方法。只是，如果您問EAV是否歸一化，並且規範化假定數據是關係型的先決條件，那麼否，EAV不是關係型的，因此不能歸一化。