1. Fall 2008
Issue 6
MySQL® Magazine
S
News, articles and feedback for MySQL database administrators and developers
using MySQL on a daily basis to provide some of the best database infrastructure
available.
INSIDE THIS ISSUE REGULAR FEATURES
2 Decision Table-Driven Development 6 Coding Corner
12 Overview of Zmanda Recovery Manager 17 Bookworm
17 log-bin

2. Page 2 Fall 2008 MySQL Magazine
Decision Table-Driven Development
By Jonathan Levin
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 begin with tweaking SQL queries. Then I replaced loops with complicated joined
SQL statements. The more I optimized towards the database, the more I improved performance of my overall
application.
Of course, this will 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?
Decision Table continues on next page

3. Page 3 Fall 2008 MySQL Magazine
Decision Table from previous page
STEPS:
1) The business user would like a new application and develops a requirements list for you
2) You start analyzing the system 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 it is 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 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 configure 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
Decision Table continues on next page

4. Page 4 Fall 2008 MySQL Magazine
Decision Table from previous page
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. 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
Decision Table continues on next page

5. Page 5 Fall 2008 MySQL Magazine
Decision Table from previous page
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 similar to the way I have always developed my applications, but with a slight difference. I
usually grab data from different parts of the database, process the data, keep the results in memory and then
throw them 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.
About the author
Jonathan Levin lives in England with his wonderful new wife. He has been developing data-driven
applications for over seven years and has been a project manager for over three years. Jonathan has recently
moved over to MySQL and tries to be active in the community. He has been writing a blog for over a year that
discusses database developing in MySQL.