什么是合适的数据结构和数据库模式来存储逻辑规则？

前言：我没有规则引擎、构建规则、建模规则、实现规则数据结构等方面的经验。因此，我不知道我在做什么，也不知道我下面的尝试是否偏离了基础。

我试图弄清楚如何存储和处理以下假设场景。为了简化我的问题，假设我有一种游戏类型，用户购买一个对象，其中可能有 1000 个可能的对象，并且必须按指定的顺序并且仅在某些组中购买对象。例如，假设我是用户，我想购买对象 F。在购买对象 F 之前，我必须先购买对象 A 或（B 和 C）。我不能同时购买F和A，也不能同时购买F和B、C。它们必须按照规则指定的顺序排列。先A，后F。或者，先 B、C，然后 F。我现在不关心购买之间的时间跨度或用户的任何其他特征，只是它们目前是正确的顺序。

存储可能数千个对象的此信息的最佳方式是什么，使我能够读取所购买对象的规则，然后根据用户之前的购买历史记录进行检查？

我已经尝试过这样做，但我一直坚持尝试实现 A OR（B AND C）等分组。我想将规则存储在有这些表的数据库中：

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

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

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

看来您的问题可以分解为测试是否满足特定条件。

你将面临复合条件。 因此给出一个项目表：

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 表的键。

这并不是为了限制你。您可以添加带有任务或其他内容的其他表格，并添加额外的动词来告诉您在哪里查找。或者，只需在完成任务后将其放入“物品”表中，然后将已完成的任务解释为拥有特定徽章。然后您可以使用相同的代码处理物品和任务。