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

The only possible benefit of using stored procedures is the possibility of accessing the database from applications that use different technologies, such as Python and Java.

Answer 2

If you don't need to perform searches based on the components of rules then you can store the rule in two fields in the database. The condition under which the statement gets executed in one and the statement that is executed in another.

id, name, description, condition, statement

Your rules can be stored using JSON or some similar format.

I'll need to define some terminology that I'll be using. There are atomic terms, system values compared to values inputted by the user that evaluate to true/false, and complex terms, terms combined using logical operators.

In an atomic term, var denotes a value that the system will provide (such as the number of visitors or number of unique visitors). Comparisons determine how the var is to be evaluated against the value. The value is a number or string that the user produces. When a var and value are both numbers, comparisons can be "<", "<=", "=", ">=", or ">". When a var and value are both strings, comparisons can be "equals", "begins with", "ends with", or "contains". Atomic terms can be stored as follows:

{ var: varName, comp: comparison, value: numberOrString }

You can store the complex terms consisting of conjunctions, disjunctions, and negations (and/or/not) using the following formats.

// Conjunction
{ op: "and", terms: [ term, ..., term ] }

// Disjunction
{ op: "or", terms: [ term, ..., term ] }

// Negation
{ op: "not", term: term }

You can then build statements that evaluate to true/false using these methods. An example is as follows:

{ op: "and", terms: [
    {op "or", terms: [
        { field: "numVisitors", comp: ">", value: 1000 },
        { field: "numUniqueVisitors", comp: ">=" 100 }
    ]},
    { op: "not", term: {
        { field: "numVisitors", comp: "<", value: 500 }
    }}
]}

The example above equates to true when the number of visitors is greater than 1000 or the number of unique visitors is greater than or equal to 100, and the number of visitors is not less than 500.

You can then execute what you refer to as a "statement" when the rule evaluates to true.

Answer 3

An argument against "soft coding" business logic like this: http://thedailywtf.com/Articles/Soft_Coding.aspx

"The reason we find ourselves Soft Coding is because we fear change. Not the normal Fear of Change, but the fear that the code we write will have to be changed as a result of a business rule change. It’s a pretty silly fear to have. The whole point of software (hence, the “soft”) is that it can change that it will change. The only way to insulate your software from business rule changes is to build a completely generic program that’s devoid of all business rules yet can implement any rule. Oh, and they’ve already built that tool. It’s called C++. And Java. And C#. And Basic. And, dare I say, COBOL."

Answer 4

So if I understand correctly you are looking to use the front end to allow people to dynamically create logic that will be applied to queries (dynamically built where clauses at runtime based on which rules are being used)?

If that is the case, you would need to be fairly specific about what conditions they can select in their rules (change in what value (column) so they can only have conditional rules against columns that exist in the dataset you are reporting from).

If I am understanding your question correctly, I would start by mapping out which tables/columns you want them to be able to select conditions against. This will be your controls for the webpage to design the rules.

However if you are just asking how to store the rules once they are chosen in the database, I would suggest storing it in a single table that contains:

ID  |  RuleSetName         |  Table     |  Column      |  Comparison  |  Value   |  Percentage  |  Notes  |  CreatedDate  |  Created By
1   |  'VisitorAnalytics'  |  Visitors  |  SUM(Views)  |  >           |  null    |  10          |  n/a    |  1/1/2012     |  JohnDoe

Then once these records are created, you will use them by injecting the tables into the from clause, columns into the where clause for your dynamic sql.

I know this may sound confusing, but what you are asking is a fairly complex solution. But ultimately you just want to store the rules together in one place where you can loop through to dynamically build then execute a SQL to generate your report. Hopefully this points you in the right direction.

Answer 5

For building reports you can convert business logic in any programming language. And use database data for generating reports.

Against of business logic stored in database

I place a high value on the power of expression, and I don't find the SQL space to be all that expressive. Use the best tools you have on hand for the most appropriate tasks. Fiddling with logic and higher order concepts is best done at the highest level. Consequently, storage and mass data manipulation is best done at the server level, probably in stored procedures.

But it depends. If you have multiple applications interacting with one storage mechanism and you want to make sure it maintains its integrity and workflow, then you should offload all of the logic into the database server. Or, be prepared to manage concurrent development in multiple applications.

Source: Arguments for/against Business Logic in stored procedures

See also:

1. Business Logic in the Database
2. Business Logic In Stored Procedures
3. Storing conditional logic expressions/rules in a database