Question

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

解决方案＃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

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

Answer 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

Answer 2

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

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

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

Answer 3

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

Attributes (id,user_id,attribute_type,attribute_value)

最终，最佳解决方案在很大程度上取决于数据的使用方式。人们只能有一个DOB，但也许你想要允许多个地址（账单/邮寄/等），所以地址可能需要一个单独的表。

友谊网站数据库设计

3 个答案: