Re: The fable of DEMETRIUS, CONSTRAINTICUS, and AUTOMATICUS

Tony Andrews wrote:

>
> Do you mean really storing the entire rule as data, or do you mean
> parameterized rules? In other words, for a rule like "daily hours may
> not exceed 24" (and please, ignoring any feelings about that specific
> rule!) do we have:
>
> 1) User inserts a row into the "rule" table:
>
> insert into rules( rule_id, rule ) values (42, 'daily_hours <= 24');
>
> OR
>
> 2) User updates a "rule parameter" value:
>
> update rule_parameters
> set value = 24
> where name = 'max_daily_hours';
>
> In the first case, you have the ultimate user control - a rules engine?
> In which case, maybe it generates DDL?
>
> In the second (more common) case, the actual rule is hard-wired into
> the system somewhere - and may as well be DDL as anything else, no?

As Marshall points out in his reply, the conversation is definitely heading towards rules engines, which give as you say ultimate user control. The danger to them is that you just create another way to have confusing code.

But to answer your question, your approach #1 above is actually 'code in disguise", you don't want that. You want approach #2 above, which is actually Tool #3 in my current road map:

1. As stated before in this thread, put everything into structure that you can. I personally have not yet found the limits to this approach. My working idea here is "totally normalize user-entered values".
2. Automation, not constraints, are the next path of exploration for me. Every job the computer can do for you is one less place where the computer has to constrain the users' actions. My working idea here is "build calculated and derived information on top of the normalized user-entered values."
3. Some type of table of user parameters will likely show up next, once I have found the limits of Unique and Referential constraints. With this approach, we would have an *automated* running total of hours logged in a day, which would be compared to the MAX_HOURS parameter stored in a user table. (And yes, this means we've come all the way back to the salary issue, and we also limit salary in this user table if it is completely unacceptable to have a table of salaries).
4. Next is the issue of resolutions. Resolutions address the problem of user parameters that are not constants, but are themselves determined by one or more domain values. An example is the default discount for an order, which may be 0% for retail, 10% for customer_type = 'DEALER' and 20% for customer_type = 'DISTRIBUTOR', except for item GONKULATORS, which gets a 15% discount only for dealers. Rules like this can be put into a table like so:

Customer_Type  Item         Discount
=============  =======      =============
RETAIL         null/blank   0
DEALER         null/blank   10
DEALER         GONKULATOR   15

In conclusion, I have worked on huge systems with hundreds of tables and have seen the above ideas implemented (though never all 4 at once) in combinations that always seemed to work without the constraint being part of the DDL.

-- 
Kenneth Downs
Use first initial plus last name at last name plus literal "fam.net" to
email me