Question

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

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

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

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

用户属性实体表

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

Answer 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]

Answer 2

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

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

然而，这将使您失去灵活性，使其在未来的增长/变化和限制选项上更加艰难。

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

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

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


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


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


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

在我的示例中，实体可以是它自己的表（如果值经常被重新执行），也可以在 UserAttributeEntities 表中放置 EntityValue direclty列，并跳过实体表。

SQL存储年龄范围

2 个答案: