Question

我正在为朋友设计一个网站，我不确定最好的方法是关于我的一个数据库表。为了给你一个想法，这大致是我所拥有的

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 。

谢谢

Answer 1

我会说“不”和“是，但是”作为1）和2）的答案。对于＃1，如果为每个首选项创建列，则您的查询将更容易管理。我曾经使用过的最好的系统都是这样做的。将首选项移动到具有“用户，首选项，值”三元组的单独表中会导致复杂查询连接多个表以检查设置。

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

Answer 2

如果数据库中的每个成员对于您列出的每个属性只有一个值，那么您的数据库已经标准化，因此形式非常方便。因此，回答＃1，将这些字段移动到另一个表中会改善一切，只会使查询更加困难。

对于＃2，如果你想考虑一个成员有多个地址或电话号码的可能性，你一定要把它们放在不同的表中，允许多对一的关系。如果您希望许多用户共享相同的地址，这也可能有意义;这样，您不会通过为多个用户存储所有相同的地址信息来复制信息，您只需引用一个addresses表，该表将在每个地址中包含一次相关信息。

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

Answer 3

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

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

例如，如果个人资料字段仅显示在个人资料页面中，并且设置字段在整个网站中有效，则无需一直查找个人资料字段。

我应该规范化这个MySQL表

3 个答案: