Question

I’m working on a project in which we will need to determine certain types of statuses for a large body of people, stored in a database. The business rules for determining these statuses are fairly complex and may change.

For example,

if a person is part of group X 
and (if they have attribute O) has either attribute P or attribute Q, 
or (if they don't have attribute O) has attribute P but not Q,
and don't have attribute R, 
and aren't part of group Y (unless they also are part of group Z), 
then status A is true. 

Multiply by several dozen statuses and possibly hundreds of groups and attributes. The people, groups, and attributes are all in the database.

Though this will be consumed by a Java app, we also want to be able to run reports directly against the database, so it would be best if the set of computed statuses were available at at the data level.

Our current design plan, then, is to have a table or view that consists of a set of boolean flags (hasStatusA? hasStatusB? hasStatusC?) for each person. This way, if I want to query for everyone who has status C, I don’t have to know all of the rules for computing status C; I just check the flag.

(Note that, in real life, the flags will have more meaningful names: isEligibleForReview?, isPastDueForReview?, etc.).

So a) is this a reasonable approach, and b) if so, what’s the best way to compute those flags?

Some options we’re considering for computing flags:

1. Make the set of flags a view, and calculate the flag values from the underlying data in real time using SQL or PL-SQL (this is an Oracle DB). This way the values are always accurate, but performance may suffer, and the rules would have to be maintained by a developer.

2. Make the set of flags consist of static data, and use some type of rules engine to keep those flags up-to-date as the underlying data changes. This way the rules can be maintained more easily, but the flags could potentially be inaccurate at a given point in time. (If we go with this approach, is there a rules engine that can easily manipulate data within a database in this way?)

Answer 1

In a case like this I suggest applying Ward Cunningham’s question- ask yourself “What’s the simplest thing that could possibly work?”.

In this case, the simplest thing might be to come up with a view that looks at the data as it exists and does the calculations and computations to produce all the fields you care about. Now, load up your database and try it out. Is it fast enough? If so, good – you did the simplest possible thing and it worked out fine. If it’s NOT fast enough, good – the first attempt didn’t work, but you’ve got the rules mapped out in the view code. Now you can go on to try the next iteration of “the simplest thing” – perhaps your write a background task that watches for inserts and updates and then jumps in to recompute the flags. If that works, fine and dandy. If not, go to the next iteration…and so on.

Share and enjoy.