Storing conditional logic expressions/rules in a d

问题:

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.)

Tags
new
for_sale
used
offer

Rule
second_hand_goods = (!new or used) and for_sale
new_offer = new and offer
second_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?

How do you guys store expressions and business rules in your databases?

Thanks in advance.

Update
To be clear, the rules are not for use internally by the database but created and used by an external application that needs to persist these tags and rules. Thanks.

回答1:

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 Tankers paper, 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.

回答2:

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...

<logic type="and">
    <logic type="or">
        <logic type="not">
            <value type="new" />
        </logic>
        <value type="used" />
    </logic>
    <value type="for_sale" />
</logic>

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.

回答3:

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.

回答4:

How about something like this:

Tables:
 tags( id, name )
 goods ( id, ... )
 goods_tags_mm ( tag_id, good_id )
 rules ( id, name )
 rules_cnf ( id, rule_id )
 rules_cnf_terms ( rules_cnf_id, tag_id )

回答5:

I would use one table

tags(id,name,type,expression,order)

• type would show if the tag is normal or calculated.
• order is reordered if you add new calculated tags, it specifies the order of the calculation for these tags...
• expression is parsed and checked before inserting a row, it could also be built using a GUI (something like how Oracle discoverer does these things).
• You only link the normal tags to the items

For your example second-hand-goods needs to be calculated before second-hand-offer, all the others can be calculated without any dependencies.

1,'new',1,'',NULL
2,'for_sale',1,'',NULL
3,'used',1,'',NULL
4,'offer',1,'',NULL
5,'second_hand_goods',2,'(!new or used) and for_sale',1
6,'new_offer',2,'new and offer',1
7,'second_hand_offer',2,'second_hand_goods and offer',2

An item could be tagged by only for_sale, calculating would give:

second_hand_goods,second_hand_offer

I would have a function that gives a list of all the tags for the item, including direct tags and calculated ones:

for_sale,second_hand_goods,second_hand_offer