• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
My Article on MySQL Magazine
 

My Article on MySQL Magazine

on

  • 2,376 views

 

Statistics

Views

Total Views
2,376
Views on SlideShare
2,370
Embed Views
6

Actions

Likes
1
Downloads
16
Comments
0

2 Embeds 6

http://www.linkedin.com 4
https://www.linkedin.com 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    My Article on MySQL Magazine My Article on MySQL Magazine Document Transcript

    • 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
    • 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
    • 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
    • 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
    • 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.