SQL 存储年龄范围答案

【问题标题】：SQL Storing Age RangeSQL 存储年龄范围
【发布时间】：2015-07-17 00:49:09
【问题描述】：

我正在建立一个友谊网站，我想存储何时可以查看个人资料的限制。

现在我使用实体属性模型来存储限制。限制的示例是配置文件可用的日期。我遇到的问题是我想对用户是否可以根据用户年龄范围查看个人资料添加限制。

我不确定这种方法是否适合存储，感觉真的很多余，但也许我只是挑剔。

我要添加的两个限制是最小年龄和最大年龄。这种设计看起来是正确的方法吗？

用户属性实体表

id(PK) | userid | attribute | entity
0      | 0      | 0         | 1
1      | 0      | 1         | 188

属性表

id(PK)  | attribute
0       | Minimum Age
1       | Maximum Age
2       | Contact Restricted Days

实体表

id(PK)  | attribute_ID | Entity
0       | 0            | 18
1       | 0            | 19
..      | ..           | ..
88      | 0            | 99
89      | 1            | 18
90      | 1            | 19
..      | ..           | ..
188     | 1            | 99
199     | 2            | Monday
..      | ..           | ..
205     | 2            | Sunday

【问题讨论】：

别在意我之前的评论，我现在看到了 userid 字段。
那么，实体表中的实体列是否存储了用户的年龄值呢？
你可以，但为什么不把 3 个额外的字段扔到用户表上... MininumAge (int -default 0), MaximumAge (int - default 200), ContactDays (int/enum/flags -默认 127) - 位编码？它将使查询变得更容易和更快。您可以创建另一个表“ContactDays”并用所有组合填充它，如果这会让您感觉更好并为其放置一个 FK。
您的方法更具可定制性，并且可以轻松扩展以包含更多属性，但您会为查询复杂性付出代价，这会影响您的性能。一切都取决于您需要解决方案的可扩展性。
那是真的，我想没有平衡。可扩展性和定制或性能。这是每个数据库设计都需要做出的选择。

标签： sql sql-server tsql optimization database-design

【解决方案1】：

我将此建议作为答案发布。但这是我设计你的桌子的方式。在每个表中都有id 列可能会导致令人头疼的问题，尤其是因为您需要显式定义该列。请将下面的设计与上面的表格进行比较：

用户属性实体表

user_attr_entity_id(PK) | userid | attribute_id| entity_id
                  0     | 0      | 0           | 1
                  1     | 0      | 1           | 188

属性表

attribute_id(PK)  | attribute
0                 | Minimum Age
1                 | Maximum Age
2                 | Contact Restricted Days

实体表

Entity_id(PK)  | attribute_id | Entity_Value
0              | 0            | 18
1              | 0            | 19
..             | ..           | ..
88             | 0            | 99
89             | 1            | 18
90             | 1            | 19
..             | ..           | ..
188            | 1            | 99
199            | 2            | Monday
..             | ..           | ..
205            | 2            | Sunday

更新：

看来我最初一定误读了您的问题。我认为这个设计会很好用。我使用下面的查询进行了测试：

SELECT userid
    ,a.attribute_id
    ,e.entity_id
    ,attribute
    ,entity_value
FROM user_attribute_entity_table uae
JOIN attribute_table a ON uae.attribute_id = a.attribute_id
JOIN entity_table e ON e.[entity_id] = uae.[entity_id]

【讨论】：

谢谢 Rookie13 我明白你对这些名字的看法了，这肯定会让我对加入的方式感到困惑。
你打赌！就像我说的，你已经很好地解决了这个问题。 :)

【解决方案2】：

如果您正在构建速度，即如果您需要优化它以存储大量数据，并且如果您知道“限制”（实体）不会发生太大变化，那么我会说设计得更扁平/水平：

Id | UserId | Restriction1 | Restriction2 | Restriction3 | ..

然而，这会让您失去灵活性，让您在未来的增长/变化和限制选项方面变得更加困难。

您的原始设计非常灵活，可以与具有语言维度的网站进行比较 - X 数量的语言对 Y 数量的元素。每个元素/实体都应该有自己的翻译，并且应该易于添加/更改。

然而，设计在某种程度上也取决于个人喜好。这就是我将以类似方式解决它的方法：

Users
-------------
UserId | Name


Attributes
-----------------------
AttributeId | Attribute


Entities
-----------------
EntityId | Entity/(or Value)


UserAttributeEntities
------------------------------------
Id | UserId (FK) | AttributeId (FK) | EntityId (FK)/or EntityValue

实体，在我的示例中，可以是它自己的表（如果经常重新使用值），或者您可以直接在 UserAttributeEntities 表中放置一列 EntityValue ，并跳过 Entities 表。

【讨论】：