我应该规范化这个 MySQL 表吗答案

【问题标题】：Should i to normalize this MySQL table我应该规范化这个 MySQL 表吗
【发布时间】：2011-07-17 02:51:27
【问题描述】：

我正在为一个朋友设计一个网站，但我不确定对于我的一个数据库表来说最好的方法是什么。给你一个想法，这大概就是我所拥有的

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 表的一部分，因为每个成员都会有自己的设置。

从长远来看，目标是大约 100000 名成员，在短期内是 10k 到 20k。我主要关心的是数据库性能。

虽然我在回答问题 #2) 移动成员的联系信息是否有意义，例如 地址街道、城市、州、邮编、电话等 strong> 进入 member_profile 表，而不是像我目前拥有的那样拥有地址表和 AddressID。

谢谢

【问题讨论】：

标签： mysql database normalization database-normalization

【解决方案1】：

我会说“不”和“是的，但是”作为 1) 和 2) 的答案。对于#1，如果您为每个首选项创建列，您的查询将更容易管理。我用过的最好的系统就是这样完成的。将首选项移动到具有“用户、首选项、值”三元组的单独表中会导致复杂的查询，这些查询连接多个表只是为了检查设置。

对于＃2：没有理由将地址放在另一个表中，因为单个“AddressID”列意味着每个成员只有一个地址，无论如何，这只会使查询复杂化。如果你把它倒过来并有一个嵌入用户标识的地址表，那么这可能是有意义的；以这种方式填写电话号码更有意义，因为人们通常有多个电话号码。

【讨论】：

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

【解决方案2】：

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

至于#2，如果你想考虑一个成员有多个地址或电话号码的可能性，你绝对应该把它们放在不同的表中，允许多对一的关系。如果您期望多个用户共享同一个地址，这也可能有意义；这样，您就不会因为必须为多个用户存储所有相同的地址信息而重复信息，您只需引用一个 addresses 表，该表将在每个地址中包含一次相关信息。

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

【讨论】：

【解决方案3】：

由于每个成员在此表中只有一个值，因此它已经标准化。但是，考虑到查询效率，有时应该考虑非规范化。

除了 ID 字段，其他可以分为 2 组：配置文件组和设置组。如果您的网站通常分别使用这两组数据，您应该考虑拥有不同用途的新闻表。

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

【讨论】：