友谊网站数据库设计答案

【问题标题】：Friendship Website Database Design友谊网站数据库设计
【发布时间】：2015-01-25 09:27:16
【问题描述】：

我正在尝试为我正在构建的友谊网站创建一个数据库。我想存储有关用户的多个属性，例如性别、教育程度、宠物等。

解决方案 #1 - User 表：

id | age | birth day | City     | Gender | Education  | fav Pet | fav hobbie. . .
--------------------------------------------------------------------------    
 0 | 38  | 1985      | New York | Female | University | Dog     | Ping Pong

我遇到的问题是属性列表不断出现，现在我的用户表有 20 列。

我觉得我可以通过为每个属性创建另一个表来规范这一点，见下文。但是，这会创建许多连接，并且我仍然在用户表中留下了很多列。

解决方案 #2 - User 表：

id | age | birth day | City     | Gender | Education | fav Pet | fav hobbies
--------------------------------------------------------------------------
 0 | 38  | 1985      | New York |   0    |      0    |     0   |     0

Pets表：

id | Pet Type
---------------
 0 | Dog

任何人都知道如何解决这个问题，感觉这两个答案都是错误的。该数据库的正确表设计是什么？

【问题讨论】：

查找“实体属性值”。基本上，您的某些属性不“值得”列，它们可以只是键值对表中的一行。
但是下拉菜单中的值怎么样，用户只能从选定的列表中输入，比如宠物的 4 种选择（狗、猫、鸟、鱼）。这值得一栏吗？

标签： sql-server database normalization

【解决方案1】：

这不仅仅是表面上看到的：首先 - 如果您有大量属性，其中许多对于任何特定行都可能为空，并且具有非常动态的属性选择（即新属性将出现在代码的生命周期中非常频繁），您可能想问自己，RDBMS 是否是实现这一点的最佳方式……本质上是非模式的。也许文档存储更合适？

如果您确实想留在 RDBMS 世界中，规范的答案是拥有一个或一个每个数据类型的属性表以及一个属性表：

Users.id | .name | .birthdate | .Gender | .someotherfixedattribute
----------------------------------------------------------
1743     | Me.   | 01/01/1970 | M       | indeed


Propertytpes.id | .name
------------------------
  234           | pet 
  235           | hobby

Poperties.uid | .pid | .content
-----------------------------
1743          |  234 | Husky dog

【讨论】：

我喜欢你的回答，但是大多数字段都是下拉菜单，例如他们不会输入哈士奇狗。他们将不得不选择猫、狗或鸟。在某种程度上，这些感觉是固定的，因为他们只能从三个选择中进行选择。如果限制为三个选项，您会将 pets 属性作为固定字段放在用户表中吗？
取决于列数以及该属性是否可能是固定的或某种易变的
我有 10 到 15 列是下拉菜单，对于每一列，用户只能输入我放在下拉菜单中的项目。你会考虑修复一个下拉菜单吗？

【解决方案2】：

您有推荐（或至少建议）和实体-属性-值 (EAV) 模型的评论和答案。

如果您的属性需要是动态的，并且您的系统需要允许在部署后添加新属性，那么使用 EAV 没有任何问题。

也就是说，如果您的列和关系都是预先知道的，并且它们不需要是动态的，那么您最好创建一个显式模型。它（通常）会表现更好，并且更容易维护。

【讨论】：

请注意，“易于维护”意味着预测未来最有可能发生什么样的变化：如果最有可能的变化是添加更多属性，而现有的属性没有变化，那么 EAV 结构与涉及非常宽的表或大量非常具体的窄表的架构相比，维护起来要容易得多。
另外，这可能是对我的评论或其他答案的回复，因为它实际上并没有回答原始问题。
是的，表格本身在 EAV 中可能更容易维护。但是维护系统比更新数据库架构更重要。

【解决方案3】：

您可以创建一个包含许多行的窄表，而不是每个属性一个字段的宽表或许多属性表，例如：

Attributes (id,user_id,attribute_type,attribute_value)

最终，最佳解决方案很大程度上取决于数据的使用方式。人们只能有一个 DOB，但也许您希望允许多个地址（帐单/邮寄/等），因此地址可能应该有一个单独的表。

【讨论】：

非可选属性也值得一列