我听说关系数据库中的决策表已在学术界进行了大量研究。我也知道业务规则引擎使用决策表，许多BPMS也使用它们。 我想知道今天人们是否在他们的关系数据库中使用决策表？
答案 0 :(得分：1)
决策表是一系列条件和行动。条件可以很简单，您可以使用简单的“匹配此值的列”字符串来表示它。或者条件可能非常复杂。类似地，动作可以像“将此值移动到列”一样简单。或者行动可能涉及多个部分或步骤，或者 - 任何事情。
SELECT或WHERE子句中的CASE函数是决策表。这是关系数据库中“决策表”的第一个示例。
您可以拥有一个“转换”表，其中包含具有旧值和替换值的列。然后，您可以编写一小段代码，如下所示。
def decision_table( aRow ):
result= connection.execute( "SELECT replacement_value FROM transformation WHERE old_value = ?", aRow['somecolumn'] )
replacement= result.fetchone()
aRow['anotherColumn']= result['replacement_value']
决策表的每一行都有一个“匹配此old_value”和“移动此replacement_value”类型的定义。
决策表的“条件”部分必须在某处进行评估。您的应用程序就是这样的地方。您将从数据库中获取条件值。您将在某些函数中使用这些值来查看规则是否为真。
决策表的“行动”部分必须在某处执行;再次，你的应用程序做的东西。您将从数据库中获取操作值。您将使用这些值来插入，更新或删除其他值。
决策表一直在使用;他们一直在关系数据库中。每个表都需要高度自定义的数据模型。它还需要一个独特的条件功能和行动程序。
它没有很好地概括。如果需要，可以将XML存储在数据库中，并调用一些规则引擎来解释和执行BPEL规则。在这种情况下，规则引擎执行条件和操作处理。
如果需要，可以在数据库中存储Python（或Tcl或其他内容）。认真。您将在Python中编写条件和操作。您将从数据库中获取它并运行Python代码片段。
很多选择。没有“学术”。事实上，基本条件 - 行动的东西一直在做。
答案 1 :(得分：1)
是否将决策表放入数据库取决于许多其他问题。
您的条件是否会在RDBMS或其他地方计算？如果可以设计用于评估这些条件的数据，以及在RDBMS内部评估它们的合适方法，那么这可能是一个好主意。也许你的行为也发生在你的数据库中，这将使它更具吸引力。
您的条件，甚至您的操作的执行可能都在RDBMS的外部，但您仍然可以在内部保持条件和操作组合之间的连接。可能是因为大多数其他数据都在那里，而你所拥有的只是一个位于其上的网络服务器。
我可以考虑两种方法对此进行建模，具体取决于您拥有多少条件（以及它们是二进制的），以及每个表的列容量是多少。
假设您有6个二元条件，这意味着您有2 ^ 6 = 64种可能的组合。然后，每个组合可以有一列，每个操作都有一行。
或者你可能有16个条件，这意味着你将拥有几乎无法估量的组合数量（实际上是65536）。这是一个荒谬的列数。最好是为每个条件创建一个列，为每个操作创建一列，并在每种可能的情况下创建65536行。每一行都代表一种情况以及在这种情况下该怎么做。您使用的唯一数据类型是bool。你也可以将这些bool打包成bitmasked整数。
实际上，更好地避免使用更大的决策表。划分和规则，并使用更多的表是一个更好的方法。如果被要求就过多条件提出意见，主题专家通常会感到疲倦。
决策表的强度实际上处于建模阶段，开发人员和主题专家可以找出是否映射了每种可能的情况，并且不存在盲点。
答案 2 :(得分：0)
我认为他们将为过去已经过多的“面对面”通讯状态做出贡献 - 足够隐藏在屏幕后面，因为它是......走出壁橱，走出去 - 得到了图片。
答案 3 :(得分：-1)
我会研究使用Object数据库而不是传统的RDBMS（关系数据库管理系统）。对象数据库旨在快速处理对象之间的层次关系，而在RDBMS中，您必须在多个表行甚至表中表示这些关系，以便您的查询（树遍历）变慢。