我應該正常化這個MySQL表

我正在爲一個朋友設計一個網站，我不知道什麼是最好的方式去關於我的一個數據庫表。爲了給你一個想法，這大約是我有什麼我應該正常化這個MySQL表

Table: member_profile 
`UserID` 
`PlanID` 
`Company` 
`FirstName` 
`LastName` 
`DOB` 
`Phone` 
`AddressID` 
`website` 
`AllowNonUserComments` 
`AllowNonUserBlogComments` 
`RequireCaptchaForNonUserComments` 
`DisplayMyLocation`

過去四年 AllowNonUserComments AllowNonUserBlogComments RequireCaptchaForNonUserComments DisplayMyLocation

（甚至更多這樣的布爾字段在將來增加）會根據用戶偏好控制某些網站功能。

基本上我不知道我是否應該將這些領域的

新表：member_profile_settings

`UserID` 
`AllowNonUserComments` 
`AllowNonUserBlogComments` 
`RequireCaptchaForNonUserComments` 
`DisplayMyLocation`

，或者我應該離開它是member_profile表的一部分因爲每個成員都將擁有自己的設置。

從長遠來看，目標約爲10萬名成員，短期內爲10萬至20萬。我主要關心的是數據庫性能。

雖然我在這問題＃2）這將是有意義的移動部件，例如地址街道，城市，州，郵編，電話等到member_profile表中的聯繫信息，而不是有地址表和有地址ID像我目前有。

謝謝

來源

2011-03-17 robert

我會說「不」和「是的，但」作爲答案1）和2）。對於＃1，如果您爲每個首選項創建列，那麼您的查詢將更容易管理。我所做過的最好的系統就是這樣做的。將首選項移動到具有「用戶，首選項，值」三元組的單獨表中會導致複雜的查詢連接多個表以檢查設置。

對於＃2：沒有理由將地址放在另一個表中，因爲單個「AddressID」列意味着每個成員只有一個地址，而且這又一次會使查詢複雜化。如果你把它往回翻轉，並有一個嵌入用戶標識符的地址表，那麼這可能是有道理的;以這種方式做電話號碼更有意義，因爲人們通常有多個電話號碼。

來源

2011-03-17 03:52:02

令人驚歎。 tnx的快速回復。關於地址表。我忘了提到用戶可以有多個地址。計費/運輸/地址將映射到某個用戶定義的事件發生在某個地方....等等。 addressID只是映射到默認地址（billing？），也許我會在member_profile表中有另一個字段，例如Default_Shipping_AddressID。這會是一個糟糕的設計嗎？ – robert 2011-03-17 04:14:29

如果數據庫中的每個成員對於您列出的每個屬性都只有一個值，那麼您的數據庫已經過標準化，因此處於非常方便的形式。因此，要回答＃1，將這些字段移到不同的表格將不會改善任何內容，只會使查詢變得更加困難。

至於＃2，如果你想考慮一個會員擁有多個地址或電話號碼的可能性，你應該把它們放在不同的表格中，以允許多對一的關係。如果您希望許多用戶共享相同的地址，這也可能是有意義的;通過這種方式，您不需要爲多個用戶存儲所有相同的地址信息來複制信息，而只需引用一張addresses表格，該表格將爲每個地址一次提供相關信息。

但是，如果您不需要每個成員多個地址，也不需要每個地址有多個成員，那麼將地址信息放在另一個表中只是不必要的複雜性。哪種解決方案更方便取決於特定應用程序的需求。

來源

2011-03-17 04:08:24

由於每個成員在此表中只有一個值，所以它已經被標準化。但是，考慮到查詢效率，應該考慮非規範化。

除ID字段外，其他人可以分爲2組：配置文件組和設置組。如果您的網站在美國獨立使用這兩組數據，您應該考慮針對不同用途使用新聞表。

例如，如果配置文件字段僅顯示在配置文件頁面中，並且設置字段在整個站點中運行，則無需始終查找配置文件字段。

來源

2013-08-14 03:49:21 screaming

我應該正常化這個MySQL表

回答

相關問題