1

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

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） 将成员的联系信息（例如地址街道、城市、州、邮编、电话等）移动到member_profile表中而不是像我一样拥有地址表和AddressID 是否有意义目前有。

谢谢

4

3 回答 3

1

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

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

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

于 2011-03-17T04:08:24.670 回答
1

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

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

于 2011-03-17T03:52:02.603 回答
0

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

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

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

于 2013-08-14T03:49:21.573 回答