听说在学术界已经对关系数据库中的决策表进行了很多研究。我也知道业务规则引擎使用决策表，许多BPMS也使用决策表。
我想知道今天的人们是否在他们的关系数据库中使用决策表？

解决方案

我将研究使用对象数据库而不是传统的RDBMS(关系数据库管理系统)。对象数据库的设计旨在快速处理对象之间的层次关系，而在RDBMS中，我们必须在多个表行甚至表中表示这些关系，因此查询(遍历树)的速度将很慢。

决策表是条件和动作的集合。条件可以很简单，我们可以使用简单的"将列与该值匹配"字符串来表示它。否则情况可能非常复杂。类似地，一个动作可以很简单，例如"将该值移动到列中"。否则该动作可能涉及多个部分或者步骤或者其他任何事情。

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"和"移动此replace_value"的定义。

决策表的"条件"部分必须在某处进行评估。应用程序就是发生这种情况的地方。我们将从数据库中获取条件值。我们将在某些函数中使用这些值以查看规则是否正确。

决策表的"操作"部分必须在某处执行；再次，应用程序完成了工作。我们将从数据库中获取操作值。我们将使用这些值来插入，更新或者删除其他值。

决策表一直在使用；他们一直都在关系数据库中。每个表都需要高度定制的数据模型。它还需要唯一的条件功能和操作程序。

它不能很好地概括。如果需要，可以将XML存储在数据库中，并调用一些规则引擎来解释和执行BPEL规则。在这种情况下，规则引擎执行条件和动作处理。

如果需要，可以将Python(或者Tcl或者其他东西)存储在数据库中。严重地。我们将使用Python编写条件和动作。我们可以从数据库中获取它并运行Python代码片段。

有很多选择。没有一个"学术性的"。确实，基本条件动作的东西一直都在做。

是否将决策表放入数据库取决于其他一些问题。

条件会在RDBMS内还是在其他地方进行计算？如果可以设计用于评估这些条件的数据以及在RDBMS内部评估它们的合适方法，那可能是一个好主意。也许操作也发生在数据库内部，这将使其更具吸引力。

条件甚至动作的执行都可能在RDBMS的外部，但是我们仍然可以在内部将条件和动作的组合之间保持联系。可能是因为我们中的大多数其他数据都在那里，而我们所拥有的只是位于其上的Web服务器。

我可以想到两种方法来建模，这取决于我们有多少条件(而它们是二进制的)，以及每个表的列容量是多少。

假设我们有6个二进制条件，这意味着我们有2 ^ 6 = 64种可能的组合。这样一来，每种组合都可以有一列，而每个动作可以有一行。

或者，我们可能有16个条件，这意味着我们将拥有几乎无法计算的组合数量(实际上是65536个)。这是荒谬的列数。最好在每个条件下都有一列，在每个动作下都有一列，并在每种可能的情况下都有65536行的内容。每行将代表一个情况以及在该情况下应采取的措施。我们使用的唯一数据类型将是bool。我们还可以将这些布尔值打包为位掩码的整数。

实际上，最好避免使用更大的决策表。分而治之，并使用更多表是一种更好的方法。通常，如果要求专家对太多条件提出意见，他们会感到厌倦。

决策表的优势实际上在于建模阶段，开发人员和主题专家可以确定是否已映射所有可能的情况，并且不存在盲点。

我认为它们会导致本来已经很衰落的状态变成过去的"面对面"通信，因为它已经足够隐藏在屏幕后面了……从壁橱里出来，得到照片。