在数据库中存储条件逻辑表达式/规则
如何使用 RDBMS 存储逻辑表达式？
我标记对象并希望能够基于这些标记构建事实陈述。 （这些可能被视为虚拟标签。）
标签新出售已使用优惠
规则second_hand_goods =（！新的或二手的）和待售new_offer = 新产品和优惠second_hand_offer = secondary_hand_goods 和 Offer
- 规则应该能够引用标签和其他规则。
- 最好是可以通过 hibernate 轻松访问的模式。
- 优选地，可以在一次选择/调用中检索整个规则。
这些规则不供数据库内部使用，而是由需要保留这些标签和规则的外部应用程序创建和使用。
How can I store logical expressions using a RDBMS?
I tag objects and would like to be able to build truth statements based on those tags. (These might be considered as virtual tags.)
Tagsnewfor_saleusedoffer
Rulessecond_hand_goods = (!new or used) and for_salenew_offer = new and offersecond_hand_offer = second_hand_goods and offer
- Rules should be able to reference both tags and other rules.
- Schemas that can be easily accessed by hibernate would be preferrable.
- Preferably it will be possible to retrieve the entire rule in one select/call.
The rules are not for use internally by the database but are created and used by an external application that needs to persist these tags and rules.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
从实用的角度来看，如果计算所需的所有列都位于同一个表中，则可以在数据库上创建计算字段 - 计算字段只能在单个记录中工作。 大多数现代 DBMS 平台都对此功能提供一些支持。
从理论的角度来看，您正在进入语义数据建模。 这方面最好的论文是 Hammer 和 MacLeods
Ruritanian Oil Tankers论文，描述了一种语义数据建模符号，被想象地称为 SDM。 SDM 使用结构化英语类型符号来标记您所描述的数据库规则。 如果您想推广您的功能并且不介意为 SDM 编写解析器，您可以创建一个可以配置此类逻辑的规则引擎。 这种类型的模型也应该能够适应 O/R 映射器。不利的一面是，制作这种工具将非常耗时，因此只有当您对管理数据语义的需求非常大时才值得这样做。 对于您引用的示例，它很适合过度杀伤的领域，但如果您的问题更大，则可能值得构建这样的东西。 如果您不想编写解析器，您可以创建一个 XML 模式来标记类似 SDM 的语言。
From a pragmatic standpoint, you can make computed fields on the database if all of the columns necessary for the computation live on the same table - computed fields can only work from a single record. Most modern DBMS platforms have some support for this feature.
From a theoretical standpoint, you are getting into Semantic Data Modelling. The best paper on this is Hammer and MacLeods
Ruritanian Oil Tankerspaper, which describes a semantic data modelling notation imaginatively called SDM. SDM uses a structured english type notation for marking up database rules of the sort you describe. If you wanted to generalise your capability and didn't mind writing a parser for SDM, you could make a rule engine where this sort of logic could be configured. This type of model should also be possible to adapt to play nicely with an O/R mapper.On the minus side, making this sort of tool would be quite time-consuming, so it would only be worth doing if your requirement for managing data semantics was very large. For the example you cite it would comfortably fit into the realms of overkill, but if your problem is much bigger, it might be worth building something like this. If you didn't want to write a parser, you could make an XML schema for marking up a SDM-like language.
管理嵌套/括号可能会变得相当复杂并且容易出错。 我过去这样做的方法是使用 XML 来定义逻辑，因为它可以很好地处理嵌套。 使用 SQL Server 2005 或更高版本，您还可以将其很好地存储在单个表中。
您的二手商品逻辑可以存储为...
很抱歉，这不是您问题的实际答案，而只是一种替代的做事方式。 我过去才发现它对我有用。
Managing the nesting/brackets can become quite complex and prone to errors. The way I have done this in the past is to use XML to define the logic as it handles nesting very well. Using SQL Server 2005 or higher you can also store this nicely in a single table.
Your second hand goods logic could be stored as...
I'm sorry this is not an actual answer to your question and just an alternative way of doing things. I've just found it to work for me in the past.
默认情况下，在我充分理解问题并找出解决方案之前，我不会将业务规则存储在数据库中。 这些属于代码。 然而，任何规则总是有例外，您可以使用 RDBMS 的存储过程和/或函数来封装这些规则（前提是您的数据库有它们）。 但是，正如我所说，理想情况下，您会在代码中以有意义的方式解释数据。
更新
抱歉，意识到我没有回答您的问题。 您可以使用函数（如果您的数据库有）允许您传入参数并返回标量值，或者使用存储过程。 每个表达式可能有 1 个，并且有一个更大的过程来以某种方式组合表达式。
As a default, until I've understood a problem well enough to figure out the solution, I would not store business rules in the database. These belong in code. There are always exceptions to any rule however and you could use your RDBMS' stored procedures and / or functions to encapsulate these rules (provided your DB has them). But, as I said, ideally, you would interpret the data in a meaningful way in code.
Update
Sorry, realise I didn't answer your question. You could use functions, if your DB has them, that allow you to pass in parameters and return scalar values, or use stored procedures. You might have 1 per expression and a larger procedure to combine the expressions in some way.
像这样的事情怎么样：
How about something like this:
我将使用一张表
对于您的示例，二手商品需要在二手报价之前计算，所有其他标签都可以在没有任何依赖关系的情况下计算。
一个项目只能通过 for_sale 进行标记，计算会给出：
我将有一个函数，给出该项目的所有标签的列表，包括直接标签和计算标签：
I would use one table
For your example second-hand-goods needs to be calculated before second-hand-offer, all the others can be calculated without any dependencies.
An item could be tagged by only for_sale, calculating would give:
I would have a function that gives a list of all the tags for the item, including direct tags and calculated ones:
如果您有一组有限的明确定义的规则或“规则宇宙”。 您可以将规则作为具有 ID 的实体存储在数据库中，然后将其类型存储在代码中查找规则实现。 最后，您还可以在数据库中包含评估规则所需的所有参数/常量/文字和/或 ER 设计中已反映的任何其他实体依赖项，例如：
在代码中，您将实现对实现规则的类实例的简单查找使用规则类型作为查找键的接口，例如
SUM_LOWER_THAN_X，在 Python 中像这样，其中参数来自数据库：这样做的优点是您的规则将存在于您的代码库中，因此可以是单位- 作为开发发布周期的一部分进行测试、版本控制和发展。
If you have a limited well-defined set of rules or a "rules universe". You could store in the database the rule as an entity with an ID, then its type which will lookup the rule implementation in the code. Finally you can also include in the database all the arguments / constant / literals needed to evaluate the rule and / or any other entity dependency already reflected in your ER design for example:
In code you would implement a simple lookup of class instance implementing the rule interface using the rule type as lookup key e.g.
SUM_LOWER_THAN_X, in Python like this where the arguments come from the database:The advantage of this is that your rules will live in your code-base, therefore can be unit-tested, version controlled and evolve as part of your development release cycles.