Re: CRUD app interface -- MIDRANGE-L

Exactly. When someone wants Joe Smith's rate of pay using, say, Excel, PHP, Javascript, .net, or the next great thing, then that business rule needs to be baked in. No responsible enterprise can waste time or energy teaching every business rule to every Super User in the organization.

On 11/9/2018 7:52 AM, Joe Pluta wrote:

That's why I've long though the term programmer/analyst is the most accurate description of what we do. This question is actually a little larger than it looks at first, but we can start with the fundamentals that we always use: identify the conditional processing which in turn depends on how the condition is specified and how it affects the processing.

In this case, the condition is pretty simple: took care of Mr. Kelly's car during the Depression. That's a function that you call that returns True or False. The devil is in the details of course. Could this apply to someone other than Mr. Kelly? Could there be a different date range? The database implementation could be as simple as a flag on the employee file, and the function could take an employee number and return an indicator. Or you could have to specify an owner ID and date range, have a vehicle master with owner ID, and a vehicle care log, and bounce the employee number against that log. But at the end of the day, you start with an employee and get a yes/no flag.

The processing is a little trickier as well. When is this rule applied? And that in turn hinges on how the rate is stored and accessed. Is there an employee maintenance function that sets the rate in the employee file? Or do you always retrieve the rate dynamically from a rate file based on the employee classification?

If the rate is stored by employee it's both simpler and broader in scope. When you maintain the employee, you update the rate. That's where you apply the business rule. Assuming that the rate is updated in the employee master based on the union position, then changing the position should change the rate. The simplest plan would probably be to have two fields: a rate and an adjustment. When you update the rate, also check the flag and if the flag is set, put .05 into the adjustment field. Then when you retrieve the rate, retrieve the sum of those two fields. So the business logic goes into the update/read of the employee record.

If instead you retrieve the rate dynamically from a rate file, you put similar logic into that function: use the employee to get the union rate, then use the employee to get the adjustment, and add the two. So in this case, the logic goes into the rate master file.

So, at the end of the day, the business logic is attached to the file whose data point is changed based on the condition. I know tha'ts pretty simplistic, but a good architectural approach is nearly always simple. That's not to say it's always easy; simple and easy aren't necessarily synonyms. But the same way that I know my code is getting better when I start removing lines, I know my design is getting better when I start removing complexity.

On 11/8/2018 8:19 PM, Booth Martin wrote:

My first eye-opening experience with business rules was the rule "Anyone who took care of Mr Kelly's car during the depression gets a nickle an hour above the union rate." That happened to be one guy. But there had to be a rule. How does one put that rule in the database?

On 11/8/2018 7:35 PM, Jim Oberholtzer wrote:

That's what a properly designed database does, enforce business rules with constraints and relational integrity built in. It's not that hard to build.

Jim Oberholtzer
Agile Technology Architects