Home/ Questions/Q 6194699
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-24T03:20:24+00:00

I am using SQL SERVER 2005. I have a table table1(ID,col1,col2,col3,col4); Now I have

  • 0

I am using SQL SERVER 2005.

I have a table 

table1(ID,col1,col2,col3,col4);

Now I have a business logic like:

If col1 >= 126 and col2 > 1 then col3 = 0
if col1 >=126 and col2 < 1 then col3 = col1+col4

Now what I am trying to do is store all these rules in database and make it data driven. THe reason for that is to give the end user more flexibility. If tomorrow the business rules changes, end user have the flexibility to change it through the GUI. For eg. if tomorrow the business wants to change the comparision value from 126 to 200 they should be able to change that through the interface. As far as possible I am trying to give flexibility like ability to change columns too like business should able to change the rule so instead of col1 they can change new rules to col2. and if possible they can also have the ability to change the operators too instead of >= they can change it to <=.

I want to change it more data driven so when the value is changes in the table we don’t need to change the code.

Is it possible to do this thing in database? Can someone suggest the data model that supports this business rules to be data driven?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Do not store code in the database. The database is for data. Code is for code.

    See the Inner-Platform Effect antipattern.

    Maaaybe you could store values like your 126 and 200 in the database, but I’d put them in a config file. But once the users want so much flexibility that you have to design a data-driven business rules engine for them, you’re totally reinventing the wheel.

    It’ll be a nightmare for you in the following ways:

    • Security risks, because user-specified expressions creates an opening for code injection attacks.
    • Testability, because you can’t predict the ranges of operations if your rules engine includes a constructive grammar.
    • Performance, because users will add tons of arbitrary expressions and sorting criteria that won’t go through performance testing and optimization before running on your server.
    • Maintenance, because users will become accustomed to the idea that they can do anything, but they can imagine reports far more complex than you can code your business rules to handle.

    Update: there are business rules platforms such as Drools, but these should have their own language for executing business rules. SQL is not the best language to do that.

    • 0