本文介绍了什么是适当的数据结构和数据库模式来存储逻辑规则?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

前言:我没有规则引擎,建立规则,建模规则,实现规则的数据结构等等方面的经验。因此,我不知道我在做什么,或者如果我尝试下面是基础。

Preface: I don't have experience with rules engines, building rules, modeling rules, implementing data structures for rules, or whatnot. Therefore, I don't know what I'm doing or if what I attempted below is way off base.

我想知道如何存储和处理以下假设情况。为了简化我的问题,假设我有一种类型的游戏,其中用户购买对象,其中可能有1000个可能的对象,并且对象必须以指定的顺序并且只在特定的组中购买。例如,假设我是用户,我想购买对象F.在我可以购买对象F之前,我必须先前购买对象A OR(B AND C)。我不能同时购买F和A,也不能F和B,C。它们必须在规则指定的序列中。 A先,然后F。或者,B,C先,然后F。我现在不关心购买之间的时间跨度,或用户的任何其他特征,只是他们是现在的正确顺序。

I'm trying to figure out how to store and process the following hypothetical scenario. To simplify my problem, say that I have a type of game where a user purchases an object, where there could be 1000's of possible objects, and the objects must be purchased in a specified sequence and only in certain groups. For example, say I'm the user and I want to purchase object F. Before I can purchase object F, I must have previously purchased object A OR (B AND C). I cannot buy F and A at the same time, nor F and B,C. They must be in the sequence the rule specifies. A first, then F later. Or, B,C first, then F later. I'm not concerned right now with the span of time between purchases, or any other characteristics of the user, just that they are the correct sequence for now.

为潜在的数千个对象存储此信息的最佳方法是,允许我读取正在购买的对象的规则,然后根据用户的以前的购买记录?

What is the best way to store this information for potentially thousands of objects that allows me to read in the rules for the object being purchased, and then check it against the user's previous purchase history?

我试过这个,但是我一直在尝试实现A OR(B AND C)这样的分组。我想将规则存储在数据库中,我有这些表:

I've attempted this, but I'm stuck at trying to implement the groupings such as A OR (B AND C). I would like to store the rules in a database where I have these tables:

 Objects
    (ID(int),Description(char)) 

ObjectPurchRules
    (ObjectID(int),ReqirementObjectID(int),OperatorRule(char),Sequence(int)) 

但是显然当你处理结果时,没有分组,你会得到错误的答案。我想避免过多的字符串解析,如果可能:)。一个对象可能具有未知数量的先前所需的购买。将理解用于处理规则的SQL或伪代码片段。 :)

But obviously as you process through the results, without the grouping, you get the wrong answer. I would like to avoid excessive string parsing if possible :). One object could have an unknown number of previous required purchases. SQL or psuedocode snippets for processing the rules would be appreciated. :)

推荐答案

似乎你的问题分解到测试某个条件是否得到满足。

It seems like your problem breaks down to testing whether a particular condition has been satisfied.

您将有复合条件。
所以给出一个项目表:

You will have compound conditions.So given a table of items:


ID_Item    Description
----------------------
1          A         
2          B         
3          C         
4          F         

并给出可能的操作表:


ID_Action  VerbID  ItemID    ConditionID
----------------------------------------
1          BUY     4         1

我们构建一个条件表:


ID_Condition  VerbA  ObjectA_ID  Boolean  VerbB            ObjectB_ID
---------------------------------------------------------------------
1             OWNS   1           OR       MEETS_CONDITION  2
2             OWNS   2           AND      OWNS             3

所以OWNS意味着id是Items表的键,MEETS_CONDITION意味着id是Conditions表的键。

So OWNS means the id is a key to the Items table, and MEETS_CONDITION means that the id is a key to the Conditions table.

这不是为了限制你。你可以添加其他表与任务或任何,并添加额外的动词,告诉你在哪里看。或者,当你完成任务,只需把任务放入你的物品表,然后解释一个完成的任务拥有一个特定的徽章。然后你可以用相同的代码处理项目和任务。

This isn't meant to restrict you. You can add other tables with quests or whatever, and add extra verbs to tell you where to look. Or, just put quests into your Items table when you complete them, and then interpret a completed quest as owning a particular badge. Then you can handle both items and quests with the same code.

这篇关于什么是适当的数据结构和数据库模式来存储逻辑规则?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

09-27 16:40