Database 存储配置
我目前正致力于推广一个平台，该平台处理收到的付款，出于抵消的原因，可能保留部分付款，然后支付其余部分。目前，该系统已被设计为处理单一类型的收入支付，但我们现在将其推广到处理不同类型的收入支付。每种支付类型都有自己的怪癖，但有很多相似之处，因此我们决定提取数据库表中每种“货币”类型之间的所有行为。这些表基本上存储用户配置，例如算法（基本上不同的代码片段，即要执行的代码的名称）、布尔值和传递的参数 我们必须为特定类型的货币存储以前配置的值的历史记录，因为配置可能会随着时间的推移而改变。最终，代码中有有限数量的配置点 解决方案 似乎基本上存在三种存储“用户”配置的总体方法。作为RBDM中的EAV表，为每个配置创建显式列，或者利用JSON/XML/其他一些文本格式 EAV EAV在使所有内容都非常通用方面具有明显的优势，因此易于从数据库中提取。最大的问题是数据完整性，必须为每种货币类型指定每个配置参数，并且在EAV中确保这一点变得更加困难。保存历史记录很简单：只需添加版本/时间戳列，然后为特定类型的货币选择最新版本 显式列 显式列，即每个配置点对应一列，使得确保所有配置点都已定义更加简单。由于最终不再增加配置点，因此它似乎比EAV更可取。然而，保持一段历史变得更加麻烦。Oracle提供了审计功能，但似乎不容易在GUI中显示自己。可以利用单独的日志表，但维护起来很麻烦，尤其是在使用触发器的情况下。每增加一列（即新的配置点）意味着必须重新生成触发器 触发器的另一种选择是在配置表中有一个版本控制列。然后，可以在配置表顶部使用一个视图，为每种货币类型选择最新的行。但是，添加一个新列会变得很麻烦，就好像它是不可为空的一样，旧行（即那些已成为历史记录的行）必须使用潜在的伪值进行更新。这显然可以通过放松不可为null的约束来避免，但由于必须指定值，因此数据完整性会变得更差 我没有过多地研究JSON/XML方法，但它似乎有许多与EAV相同的问题Database 存储配置,database,oracle,Database,Oracle,我目前正致力于推广一个平台，该平台处理收到的付款，出于抵消的原因，可能保留部分付款，然后支付其余部分。目前，该系统已被设计为处理单一类型的收入支付，但我们现在将其推广到处理不同类型的收入支付。每种支付类型都有自己的怪癖，但有很多相似之处，因此我们决定提取数据库表中每种“货币”类型之间的所有行为。这些表基本上存储用户配置，例如算法（基本上不同的代码片段，即要执行的代码的名称）、布尔值和传递的参数 我们必须为特定类型的货币存储以前配置的值的历史记录，因为配置可能会随着时间的推移而改变。最终，代码中有
我的问题是：有没有一种标准化的方法来处理这个问题？似乎大多数处理用户配置的人也不必在表中保留确切的历史记录。可以简单地使用创建的迁移SQL文件，但也可以从GUI更改配置 当你讨论Oracle的“审计功能”时，不确定你在想什么，但它的闪回数据归档功能使用起来非常简单，似乎与GUI完全兼容。[了解更多信息]（）不幸的是，该系统是分布式整体的一部分，因此使用了共享数据库。闪回查询有一个相当短的保留期（想想天），我们需要永久保存历史记录。您对EAV假定优势的评估非常乐观。它不但没有使提取数据变得“容易”，反而使提取数据变得更加困难。好吧，在这种情况下，配置消费者总是知道钱的类型+有问题的配置类型。它形成所需特定配置值的唯一键。这就是为什么EAV在这方面不是一个糟糕的设计。与其使用触发器来维护历史记录，不如使用一个
start\u datestart\u date