【问题标题】:Modelling access restrictions to records对记录的访问限制建模
【发布时间】:2012-11-15 09:48:54
【问题描述】:

向数据设计大师寻求一些集体智慧...

我正在编写一个基于网络的游戏(本质上是一个网络应用程序)。游戏动态需要在授予/拒绝成就之前进行访问检查。

我的游戏需要精细控制谁/何时可以访问某些成就。这些成就要求各不相同,可能是以下任何一项的组合:

  • 用户必须查看某些内容(有一个存储此访问信息的表)
  • 用户必须等到获得访问权限(例如,在帐户创建 2 周后才能访问记录)
  • 用户必须已响应事件(例如消息)
  • 用户必须回答过问题(例如游戏内投票)

但是我不能对这些进行硬编码,因为游戏允许为每个游戏大师创建自定义“宇宙”。因此,每个游戏大师都应该能够创建/更改在他/她的“宇宙”中授予成就的方式。

我在想出一个数据库设计来允许为成就记录存储这些限制时遇到了困难。有没有什么好的通用设计模式来存储这种信息?有什么有用的书籍、网站吗?

欢迎提出任何想法和建议。

PS。我尝试过 Google-ing,但返回的大多数点击都是关于如何控制对数据库的访问,而不是如何设计存储这些信息的表。

【问题讨论】:

    标签: design-patterns database-design


    【解决方案1】:

    您正在做的是建模状态。最常见的状态建模方法是使用状态转换表。

                View something | Wait     | Respond | Answer
                ----------------------------------------
    User 1        view action  |          | resp act|
    User 2                     | wait act |         |
    User 3                     |          |         | answer act
    

    等等。

    编辑添加:该表仅包含状态信息。您的代码必须知道如何设置状态表以及当一个状态或状态组合完成时该做什么。

    【讨论】:

    • 感谢您的回复。如果我理解你的设计,我最初的想法很接近这个。我有一个AchievementRequirements 表。但它不允许我拥有像(必须查看 X、Y、Z)这样的多部分成就。这可以被认为是“视图 X 和视图 Y 和视图 Z”。这也提出了如何存储 AND/OR-ed 成就要求的问题。例如:(查看 W 和查看 Y)或回答 G。我很难想出通用设计来将这些东西存储在数据库中。
    • 你必须在状态下思考。在您的第一个示例中,视图 X 的操作是视图 Y。视图 Y 的操作是视图 Z。视图 Z 的操作是视图操作。当然,您必须处理 X、Y 和 Z 的排列,这样您就不会依赖于顺序。在您使用 OR 的第二个示例中,您仍然处理状态。
    • 我想我们是从不同的角度考虑这个问题的。我正在尝试为成就建模可修改的要求,而不是为每个用户存储成就的状态。然后,我的代码将在授予对某些内容(例如成就)的访问权限之前实时检查是否满足存储的要求。如果未满足要求(或此后已更改),则无法访问。
    • 我已经将状态存储在各种表中(访问的页面、民意调查、回复的消息)。我发现困难的是基于多个标准对访问限制进行建模。例如。要访问一个成就(能够查看某些东西或其他什么),我检查了这个要求表(可能是查看 X,回复 msg M,并且仅在注册帐户后 2 周)。一旦我可以存储这些需求,我就可以编写通过所有这些需求的代码来检查它们。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2013-12-30
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多