
Ask HN: Would you implement a decision table library, in 2015? - andima
I would really appreciate the HN&#x27;s community advice on this topic.
My requirement is to take decisions based on a common mechanism, not a workflow but merely a matching approach via a decision table (the concept has been pushed as a solution since the beginning, refusing rule engines and wishing to get rid of if-else code). The proposed solution is a decision table, with decision conditions (a column) and actions (another column) + some operators (boolean, any, not, business-like) in order to have a reusable library, matching a set of decisions based on a provided decision table and a matching function, semantically free, via decision table definition in XML, decision table manageable in memory, dynamic SQL creation.
However, I do not really support this solution as I think performances, scalability and clustering (if in-memory-table would be used) would be seriously impacted. And the library would then end up as not-so-reusable and force its consumers to workarounds&#x2F;adaptations&#x2F;steps-back. Moreover, I see several principles which could be easily broken: KISS (Keep it Stupid Simple), YAGNI (You Ain&#x27;t Gonna Need It), somehow also PLA (Principle of Least Astonishment). Too many buzz words perhaps, but the alternative would probably be to use an existing product (OpenL Tablets, DTRules, JBoos Drools) or rethink the solution just via Design patterns appliances (if you really don&#x27;t want to see if-else everywhere).<p>Would you really implement a decision table library in 2015? Would you actually use decision tables in your application or push for other alternatives?<p>Thanks a lot!
======
pjungwir
If this is to cut down on if-else code then I'd say it depends on how many if-
elses you're saving.

More often I see people take this approach to let end users compose rules for
various actions. But this kind of thing tends to be what I call a "Turing
complete" feature, where people are always writing rules that go beyond what
your model can express. ("If there are two of these, and one is not older than
this, and their mean is greater than the most recent of these, and the current
time is before 8 a.m. in the time zone of the user who owns this user's
account . . .")

In that case, if your users are sophisticated enough (e.g. internal users in a
"services" division of your company), you might want to consider going with
embedded Javascript instead. You can expose a few objects/functions from your
application and let people write JS using them. Then you run their JS and see
if it evaluates to true. I've used this in a Ruby context before with the gem
therubyracer.

This is nice because your app gets a full-featured scripting language for
free. You don't have to design the language or write an interpreter.
Javascript is designed to be very secure. It can't do IO or run shell
commands. And it's probably the most widely-understood programming language
out there, so there's a low learning curve.

Challenges are that your users have to understand a programming language, and
you'll probably want to take steps to validate the Javascript they're writing
and to surface decent error messages when problems happen. Also therubyracer
can use a lot of memory, which may or may not be a concern depending. Another
challenge is that the JS will be opaque to an outside computer system. It's
hard to break it down and express what it's all about. For instance you
couldn't run a query to find all actions that require condition foo.

Good luck!

------
davismwfl
Rules engines are awesome and are super powerful, but add a layer of
complexity that is not inconsequential. I have implemented a lot of rules
engines, and removed a fair number of them too since the late 90's. I
generally removed them because they created a dependency nightmare, added
crazy complexity and required significant extra test conditions that the
application just didn't need to have. This can slow your development down
considerably for smaller applications and cause great frustration. Which is
not what a rules engine should do.

My basic starting thoughts is that if the rules are well known, change
infrequently, have minimal nested chaining and number < 50 or so then I'd opt
for having a good design pattern or simple if/else within the code. If you
violate any of these tenants, then I'd look at decision tables/trees first,
then after that move to a rules engine. Of course, if users are required to
write their own then that would also have to factor in to this decision. BTW
-- Don't dismiss a good design pattern or even a plug-in pattern as sometimes
that is more than enough to solve moderately complex rules without adding
additional dependencies or significant development complexity.

If this is an application that will be deployed to third party sites, then
again, I generally opt for a balance between the number of dependencies and
the application maintenance. If it is deployed behind a website or application
where your company controls the environment, then I focus more on flexibility
and application maintenance than dependencies.

Also, in a few less common scenario's, I have written very basic purpose built
rules engines that solved some of the key issues without creating needless
complexity, maintenance or dependency nightmares. Not that I advocate writing
libraries/code that already exists, but many times you just don't need a
Drools, or ilog rules etc. Also, this is where something like embedded
JavaScript is a handy tool as pjungwir also mentioned.

------
canterburry
Why don't you just use drools decision tables?

[http://docs.jboss.org/drools/release/5.3.0.Final/drools-
expe...](http://docs.jboss.org/drools/release/5.3.0.Final/drools-expert-
docs/html/ch06.html)

