HiWould it be possible for you to share some details of your solution. I'd like to know how many rows did you process using your rule engine in the 10 min duration, how you managed the network cost of retrieving and persisting information from the database, and how many rules did you typically have to apply on each row.
I don't know about the case above, but I have seen cases where a database driven approach was 10x slower than using a general purpose rule engine like JESS. one of the issues limiting database driven business processing is handling it incrementally. Say you have a business process that collects several screens of data from a user, which trigger other business processes. In a simple case like processing loan applications, the user fills out the form, and submits the information.
After that, the system may need to get the user's credit information, since the loan processing can't continue without that. After the information is retrieved, the user may need to verify it is accurate. If one did this using database, the steps might look like this.
1. save user data
2. db trigger runs stored proc
3. stored proc inserts a row into GetCreditRating
4. some external business process would need to constantly poll the database and see if there are entries in the table
5. the process gets the user's credit rating and save it to the db
6. another trigger checks to make sure rating meets the minimum and then categorizes the user
7. a row is insert into another table
8. yet another business process monitors the tables to see if it should send an email to the application and sends an email
9. the user recieves the email and verifies it
10. the system saves the verification and changes the state of the application
11. another trigger sorts the application by category based on 2 dozen rules.
12. the loan officer looks at the application and contacts the person
A real loan processing application does much more than this, but it should provie a rough picture. The first thing about using a database for this type of application is it impacts the database and reduces it's ability to handle transactions. The second is you're making the database store a lot of temporary information which need to be update/deleted as the application goes through the process.
Now, consider a business may need to process several hundred applications per day along with all the other normal database work. It makes sense to off load the business process to a rule engine. Then again, I'm bias :)
if you look on ACMQueue, you'll see plenty of papers that go into detail why database driven rules generally do not scale as well as using a rule engine.