SQL 存储年龄范围

Question

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

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

我不确定这种存储方法是否正确，感觉确实多余，但也许我只是挑剔。

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

用户属性实体Table

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

属性Table

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

实体Table

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

Answer 1

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

用户属性实体Table

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

属性Table

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

实体Table

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]

Answer 2

如果您正在为 speed 构建，即如果您需要优化它以存储大量数据，并且如果您知道 "restrictions"（实体）不会有太大变化，那么我会说设计它 flatter/horizontally:

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

然而，这会降低您的灵活性，使您在未来变得更加艰难 growth/change 并限制选择。

您的原始设计非常灵活，可以与具有语言维度的网站进行比较 - X 种语言在 Y 种元素上。每个 element/entity 都应该有自己的翻译，并且它们应该很容易 add/change。

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

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


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


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


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

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

SQL 存储年龄范围

SQL Storing Age Range

sql

tsql

sql-server

optimization

database-design