Set Processing vs Complexity

There was a time when I was a fervent member of the Church of Set-Based Processing. I preached %InsertSelect and TAO tables, and I would brook no dissent. At the time I was writing app engines to bring data into Projects, and it's probably a fair bet to say that PROJ_RESOURCE is one of the largest tables in the Financials database.

On a recent project I had a requirement to allocate available quantity against incoming orders. I dutifully built an app engine that handled most of the work in a set, only dropping to a row-by-row loop at the end. It took a little debugging, I got turned around once or twice, but in the end it was fast and—if you don't mind me saying—somewhat clever.

But here's the thing: while the business analyst was congratulating me on how fast the process ran, he mentioned some of the rules he'd like to add in the future. (I know, new requirements. Who would have guessed?) I had architected for some flexibility, but had no room for the complexity he wanted to add. I could twist the clever knife a little deeper, but then woe be the developer that had to debug or add functionality down the road.

I wondered then if another tool might have served me better. Rather than temp tables and recursive DoSelect's, what if I had built logic with app classes? It's much clearer to write rules in PeopleCode than in recursive app engine steps with state records. And by their nature app classes are easier to extend.

When a similar requirement came up later in the project I did a little testing. I wrote some test code that created a set of objects in a PeopleCode event. They were very simple, bean-like objects that held keys and a few additional fields. I created 5,000. Then 10,000. Then 50,000. It took only seconds. The tests to update the table behind the objects performed similarly.

Writing business rules in PeopleCode is an order of magnitude easier. You can encapsulate complexity in classes and methods in a way that app engine sections just cannot approach. The process is easier to maintain, easier to test, and much, much easier to extend.

Now let's be clear, I'm not saying I'm leaving the Church of Set-Based Processing. (I still resolved my run control criteria with an InsertSelect into a temp table in the first step, then worked from there.) But I did learn that implementing complex business rule need not be complex. Sometimes PeopleCode and app classes are the right tool for the job.