Friday, June 25, 2010

Data Structures for Data Processing

I'm sort of thinking out loud here - but this is a compare/contrast of two ways of handling data on a form. Recently, I've completed two web applications, both of which were the electronic web-forms of what were paper medical forms. I took two distinct approaches to handling the data on the client side (in the browser).

In the first form, I held all data inside a structure. The user would enter the data in textboxes, dropdown lists, etc, and when clicking the “save” button, the first thing my code would do is gather up all the data into a data structure. I did this so that when it came time to do any kind of processing on the data, I’d have a structure that I could easily parse through. So all parsing/interrogations of the data could be done with loops, thereby saving valuable coding time. Similarly, when the form loaded up, I grabbed data from the database and put it in the data structure – then delivered it to wherever it needed to go on the form (back into the correct textboxes, and so on).

In the second form, I avoided this approach. Instead, all data going to and from the database is done individually. It just so happened on this form that there was a lot less data to move around, and since designing/implementing a data structure and generic processing engine for the structure would’ve cost more time, I opted to manually move/interrogate data. I estimated that due to the smaller amount of data for this second form, this approach would save me more time in the long run.

What appears to be happening, though, is that the first approach would’ve been better. As us experienced developers know, projects can sometimes be like roller coasters – unexpected twists, turns, speeding up, slowing down, or sometimes outright stoppages. Sometimes scary, sometimes not so much. For the second project, I’ve had to make modifications to how much data is displayed on the form and how it is laid out. With a generic processing engine, doing this would just be a matter of configuration and a few lines of code. But since I chose to explicitly write everything out, I’m now paying the price of extra time in executing these changes. Have I equaled the time I would’ve spent designing a generic solution, like I did in the first example? Yes, I think I have.

So, the moral to this story is that when you’re moving lots of data around, and even if you’re just interrogating it a little, put it in a data structure so that all processing/interrogation can be done with loops. Not only is it worth the extra time, but it’s fun to design the structures and loops themselves. Speaking of time... I’d better get back to moving that code manually.

No comments:

Post a Comment