Decision Table Driven-Development

I have been trying for a while now, to find ways to improve the data-driven applications I work on by leveraging the database. I started my way with tweaking SQL queries. Then moved my way up to replacing loops with long and complicated joined SQL. The more I optimized towards the database, the more I improved performance of my overall application. Of course, this might not be news to many of you. So I tried to come up with some ways of improving the speed even more, but the only way I saw myself doing that is if I put some application logic in the database.
At least to the point where the database could arrange itself to use the data more in-line with how I wanted it to be used.
I did some research (actually a lot of research) and found out that the most convenient form of logic capturing tool was decision trees and decision tables. I developed a method that I want to share with you about how I believe decision tables can help you develop data-driven applications and speed up your database queries.

How can developers use this?

1) The business user would like a new application and writes down a list of requirements for you

2) You start analyzing the system a bit and write down what kind of data you need to keep. You then start

designing an initial idea for a database.

3) You ask what kind of decisions you need to have for the new application and then make decision tree

diagrams. You can then show the diagrams to the business user to see if you are on the same page.

Some examples:

a. What discount should a new customer get?

b. When is it ok to go outside and play a baseball game (according to the weather)?

c. Does the hotel have available rooms?

4) You can convert the decision tree into a decision table, which naturally fits database tables where you

can store it.

In this example, you can see all the possible options for when a hotel will have available rooms or not.

This can also be called a “Truth Table”, because it only holds True or False.

5) Now its time to go to your application code (or your database code).You write code to process the

conditions and store the result in the database. You can store the results in a separate table from the

data you are referring it to because of versioning reasons. After you have all the conditions processed

and saved, you can search the decision table for the result to the decision you are looking for and save

it to your table.

6) There are also ways to create and search decision tables by minimizing the rows by using “All”

(meaning, in all cases for this condition) instead of True/False. In the event where you forgot a certain

situation (or tree branch), you can setup your application to add a new row to your decision table for

that situation and to message you to fill it in later. This helps with debugging behaviour.

7) It is important to note that there is an element of Test Driven-Development here. The idea of creating

tests first is to help discover what your program should do, run the test to check if it works and then

“flesh out” the code to make the test pass. Here you use the conditions to help you create tests - Null

for fail and True/False for pass. You also know what the application should do because you planned it

when you thought of which data types you need to store. Lastly, you are largely relieved from writing

conditional If-Then-Else statements (which needs testing for possible side effects), because they are in

your decision tables.

8) Finally, Test the code again as well as the code behaviour.

9) You’re done. – Done is a very loose term, but for the purpose of this example, you are done.

What are the Benefits?

1. I already talked about the benefits for developers. It helps the coding process by defining what you

should code and it sets up tests in a way to verify your code. Since you keep records of the results for

the conditions, you have records for debugging.

2. Because of the similarity of decision tables and database tables, there is an opportunity to be able to

alter them and by doing so, you can change the behaviour of the application. In the events of larger

changes, such as adding conditions and results, you have a lot of control for maintenance and testing.

3. Finally, since the database has more information about your data and how it relates to what you need,

you can produce very fast queries and reports. In the example of the hotel-reservation system, you can

do a search for which rooms are available according to “WHERE available = True”.

4. It is also important to note, that the logic is not necessarily held in the database, if you are really

against that. The code is the logic which does the “How” and the database holds the results which is

the “What”.

Conclusion

I see this method as the same way as I have always developed my applications, but with a slight difference. I

usually grab data from different parts of the database, process it, keep it in memory and then throw it away

when I am done. This time I just decide to keep the results in the database for later.

While using this method, I really felt very surprised at the end of the development process and how easy it

was to get to it. I felt a bit like I was “cheating” while I was working on the code, because I already knew all

the answers.

I am very happy with how this idea turned out. I am particularly happy with the testing element and the

maintenance element which I know helps cut down on problems in development and keeps the application

going for a long time.