The easy ones (attribute and tuple rules) should be implemented by the declarative integrity constraints offered by Oracle: primary key, unique key, foreign key, not null and check constraints. However, the more challenging static constraints: the entity and inter-entity constraints can be handled perfectly with RuleGen. Change event rules (if A happens, then you should do B) should be considered as business logic instead of static database constraints, and are best to be handled in a calling api.
Examples of the type of constraints that were shown in RuleGen, are:
- There can only be zero or one employee with job 'PRESIDENT'
- Each department with a PRESIDENT or MANAGER should have at least one ADMIN.
Although I have stated that database triggers are evil, the main disadvantages I stated there seem to be addressed by this framework:
1) Database triggers make things happen "automagically"
This does not apply here, since RuleGen only considers the static database constraints.
2) Database triggers are rarely implemented correct
Here the appropriate locking code is generated by a dbms_lock call. In the version shown it was optional, but it will soon be mandatory and it can be derived from the definition.
3) Database triggers slow down DML
This will still be true since row level database triggers are generated and thus the dreaded contextswitches have to be performed. However the trigger code itself seems to be relatively lightweight - I'll have to test this. And more important, multirow DML is capable of checking the rule only once instead of "for each row". Undoubtedly RuleGen will outperform CDM RuleFrame. In the near future, I hope to be able to investigate how well RuleGen performs compared to the api approach.
To be continued...
UPDATE
You can read the results of the performance test here: RuleGen: the test
No comments:
Post a Comment