SQL-Based Rules

Previous Next

Behavior and restriction rules can be entered in USoft Developer in a non-procedural fashion. They are called constraints in the repository and are stated in SQL. Defining business rules as constraints is a very efficient way to develop applications, for several reasons:

· Atomic definition of the rule.

The rules are entered individually, and it is up to the Rules Engine to ensure that rules are evaluated in the right sequence and combination.

· Limited dependency on the time at which the business rule should be evaluated.

Normal programming requires one to keep in mind the evaluation of the business rules at any possible moment. There is code for pre-update, post-update, pre-delete, and so on. This leads to various software replicas of the business rules (that each need to be written, tested, and can differ). The Rules Engine takes care of this itself; it is only necessary to state what is not allowed, or what is to happen in a certain situation, regardless of how the situation evolves.

· The business rule can be translated into constraints regardless of the context or order in which data is manipulated. Usually there are many situations in which a rule can be evaluated. Take, for example, a rule that calculates the price of an order. This calculation becomes incorrect if, for example:
· A new order line is added or deleted.


· The quantity in an order line is updated.


· The article price is updated.


· The order's discount percentage is changed.

All of these situations are covered automatically by the business Rules Engine, independently of the sequence in which the users UPDATE, INSERT, or DELETE.

The resulting situation is an extremely clear single point of definition. The programming, and therefore maintenance, is reduced to business rules definitions, stating:

· What should happen in certain situations?


· What is not allowed to happen to the information?