我应该规范化这个MySQL表吗

我正在为一个朋友设计一个网站，我不确定最好的方法是使用我的一个数据库表。 给你一个想法，这大概就是我所知道的

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

最后四名

AllowNonUserComments

allownonUserLogComments

requireCAPTCHAFERNONUSERComments

DisplayMyLocation

（将来可能还会添加更多类似的布尔字段）将根据用户偏好控制某些网站功能

基本上，我不确定是否应该将这些字段移动到

新表：成员配置文件设置

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

或者如果我把它放在会员档案表中，因为每个会员都有自己的设置

长期目标是大约10万名会员，短期目标是10万至20万名会员。我主要关心的是数据库性能

在我讨论问题2时，将成员的联系信息（如地址、街道、城市、州、邮政编码、电话等）移动到成员个人资料表中，而不是像我现在这样有地址表和地址ID是否有意义

谢谢

我会说“不”和“是的，但是”作为对1）和2）的回答。对于#1，如果为每个首选项创建列，查询将更易于管理。我使用过的最好的系统就是这样做的。将首选项移动到一个带有“user，preference，value”三元组的单独表中会导致复杂的查询，这些查询连接多个表只是为了检查设置

---

对于#2：没有理由将地址放在另一个表中，因为单个“AddressID”列意味着每个成员只有一个地址，而且这会使查询复杂化。如果你把它反过来，并有一个地址表，嵌入用户ID，那么这可能是有意义的；这样做更有意义，因为人们通常有多个电话号码。

如果数据库中的每个成员对于您列出的每个属性都只有一个值，那么您的数据库已经规范化，因此形式非常方便。因此，为了回答#1，将这些字段移动到另一个表不会有任何改进，只会使查询变得更加困难

至于#2，如果你想考虑一个成员拥有多个地址或电话号码的可能性，你肯定应该将这些地址或电话号码放在不同的表中，允许多对一关系。如果您希望多个用户共享同一地址，那么这也可能有意义；这样，您就不会因为必须为多个用户存储所有相同的地址信息而复制信息，您只需引用一个

地址

表，该表将为每个地址提供一次相关信息

---

但是，如果您既不需要每个成员有多个地址，也不需要每个地址有多个成员，那么将地址信息放在另一个表中只是不必要的复杂性。哪个解决方案更方便取决于您特定应用程序的需要。

由于此表中每个成员只有一个值，因此已对其进行了规范化。然而，考虑到查询效率，有时应该考虑非规范化

除ID字段外，其他字段可分为两组：配置文件组和设置组。如果你的网站分开使用这两组数据，你应该考虑有不同用途的新闻表。

---

例如，如果配置文件字段仅显示在配置文件页面中，而设置字段在整个站点中工作，则不必一直查找配置文件字段。

wow mazing。tnx的快速答复。关于地址表。我忘了提到一个用户可以有多个地址。将映射到某个地方发生的用户定义事件的帐单/发货/地址。。。。等addressID只是映射到默认地址（账单？），也许我会在member_profile表中有另一个字段，比如default_Shipping_addressID。这是一个糟糕的设计吗？