Storing conditional logic expressions/rules in a database

Question

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

Answer 1

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.

Answer 2

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

Answer 3

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 )

Answer 4

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.

Answer 5

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.