Storing Business Logic in Database

Question

We want to write some business logic rules that work on top of certain data to build reports. Not sure which is the best to store them in the database MySQL.

Answer 1

I think what needs to be done first is question whether or not you should be putting the rules in a database to begin with.

Databases are a heavy handed solution, and are often simply not needed.

Having dealt with rules engines in various forms, including database driven, I can tell you it can get really frustrating and unproductive, really quickly. One of the big mistakes I've seen happen is attempting to write your own ad-hoc rules language and using that to drive conditional logic via the database. At the very least, use a language that's already proven (Python, javscript, etc) and embed that in there.

Even better- if the rules are sufficiently complex, I personally prefer to employ Excel spreadsheets. We use this for automation (to handle variable logic based on effective date, etc), and we also compile rather complex insurance rating logic to Perl scripts interfaced via a web service, using this product: http://decisionresearch.com/products/rating.html.

Contrast storing the logic in a database versus, say, an Excel spreadsheet:

1. Logic in the database is harder to test and develop for compared to Excel, because Excel provides instant feedback.
2. A database is less (much less) expressive compared to Excel.
3. You can color code and add all sorts of other visual cues to Excel to make error conditions, etc, really stand out.

Now of course, as you can imagine, a web service driven Excel rules engine isn't going to fit every situation. And it's not the only possible solution here.

What I'm getting at though is that make sure you're making the right trade offs in terms of usability/expressiveness/testability/performance. Where I work, being right and being productive is more important than being fast in execution, so we go with the Excel/web service.

And to expand on slavik262's comment, what you really want to achieve with rules engines, ultimately, is abstraction and generalization, to minimize moving parts and increase reliability, testability, and understandability. A database rules engine, in my experience, is sub-optimal in comparison often to even simply just making, say, Java based rules. As long as they're sandboxed and organized properly, and hide behind a generalized and consistent interface, then they work just fine.

At my company, it depends on the scale of the rules and how often they change as to what we go with. Rating insurance- Excel, no question about it. Some state specific logic? Interfaced Java rule files suffice just fine.