To Normalize or not to Normalize?

Normalization is an important concept in database design, but is it always practical? This is a question I’ve been hit with head-on while working on a recent project at work. Now, there’s more at play here than simply normalization. Our overall site design executes an excessive amount of business logic in the database tier, which makes me cringe. Here’s why.

• Databases are almost always the least fault-tolerant layers in an application


• Databases are almost always harder to debug and troubleshoot than other layers in an application.


• Databases are written to read and write from disk efficiently, and apply set operations on groups of data. Branching logic, string manipulation, and the like are convenience tools only.


• Enterprise databases are really expensive and much harder to scale horizontally.

These ideas have been beaten into my head over the past 4 years or so, and they make a lot of sense (or I'm just brainwashed).

The next point is a matter of maintainability. Let's say you've got a stored procedure that's about 150 lines long that contains some conditional logic and is joining across 7 or 8 tables in multiple branches and in various sub-selects. Now, you have to add a whole new set of functionality, but to do so, you have to integrate data filtering that exists across 9 or 10 new tables. Now lets add another real-world variable to the equation...turnover. What happens to the poor bastard that inherits this beast? To me, this is far more costly than any performance loss that is incurred by introducing complex joins and decision logic.

Now don't get me wrong--I'm not anti-normalization. In fact, it should probably be the first thing considered in any data modeling. But normalization-for-the-sake-of-normalization can be a slippery slope in terms of an application's agility and maintainability. Embrace best practices, but question them as well. There are people out there who make a lot of money selling enterprise database software so be careful about whose Kool-Aid you drink.

Rolling Your Own AJAX (Part 3)

I'm looking through the Ajax library source code and noticed something that made me laugh. Three of the five objects were written using JSON and the others were constructed the more traditional way (creating functions to represent the object and defining members using the "this" keyword). Normally, I'm not this inconsistant but hadn't used JSON before and wanted to develop some proficiency. The reason being that deserializing JSON into a native JavaScript object is considerably faster than creating and working with an XML document (although there are security implications). That said, I think any reusable framework needs to support should probably support both, as well as simple string responses.

One of the challenges I ran into when coding this model was getting the message data to be accessible to the context object. The problem was this--the message contains a pointer to a callback function along with a reference to the request object. What I wanted to do was pass the entire parent message object to the callback. This would allow all of the request and response details, along with the properties of the message to be available when synchronized back to the main execution thread. But there's a problem.

The issue came with the "this" keyword. The AjaxMessage object contains a method called "process" which obtains a reference to a request object. This is temporarily stored in a property and the message object calls the "send" method of the request. When the onreadystatechange fires, the context becomes the request object; the reference to the parent message object is lost.

This was actually a simple fix for Firefox. The open-endedness of JavaScript objects would allow a property to be added to the request object with a reference back to the parent AjaxMessage. IE however is a different animal. The HTTPRequest is not exposed as a native JS object, but rather as an ActiveX control which plays by its own rules. This is actually related to the inability to cover a select box with a div object without the use of programming trickery (I prefer the iFrame shim myself). This problem gave me fits for over a week. So what was the solution?

It actually turned out to be pretty simple and logical. I was able to create a local variable that contained a reference to the AjaxMessage within said message.
When the "this" keyword picked up the HTTPRequest reference, I was able to get back to the message by passing the local reference as an arguement to the callback. At this point you may be thinking the same thing I was...with all this circular referencing going on, have we created a memory leak? The short answer is not that I've seen yet, but I'll go into further detail in a future blog.

Anyway, I've been using the Ajax library for a while now and have had great results. It's small (about 400 lines of code), reliable, handles a variety of page types and load, and very easy to plug in and use. If anybody is interested, you can download it here and use it at will. I'd love to hear about any bugs, feature requests, or general feedback.

Rolling Your Own AJAX (Part 2)

I left off talking about some of the perceived UI benefits of using AJAX. What I'd like to cover now is how I modeled the AJAX client library for this project. I did some research into some of the existing solutions, and there is some good stuff out there. Dojo is a very robust client-side library that goes way beyond simple AJAX functionality, and there a couple of .Net frameworks available, too (Ajax.Net and Atlas come to mind...I'm sure there are many more). For the project at hand, I decided to construct a framework from scratch--a direction I almost always lean toward.

Here is the object model I came up with, and the general rolls each would play:

• AjaxMessage: This object encapsulates a single callback to the server, and contains the request details, response details, and handling details (a reference to the callback function). It also contains the actual HTTP request (which I will most likely decouple when I refactor this puppy).


• MessageBuffer: This object is essentially a traffic controller, and determines how messages will be handled in the context of the page. When going through possible AJAX use-cases, I felt like we needed a lot of control here. In the project at hand, the user had the ability to request information faster than it could be processed. The MessageBuffer object can be set up to send messages immediately or in batches, and can filter duplicate messages.


• MessageCache: This is a repository for "cachable" messages. If a message is deterministic (will return the same results with the same inputs), it can be cached and the return data accessed later without going back to the server. This object manages cache settings including capacity, threshold, and expiretype (messages can be set to expire after a given amount of time, or via a least-frequently-used algorithm.)


• CacheObject: This is simply an AjaxMessage object with cache meta-data.


• Request Pool: OK, this was something I coded before had fully researched it. The idea was to create a pool of HTTP Request objects when the AjaxFramework is initialized to avoid the overhead of object creation for each request. Great idea in theory, right? The problem is the HTTP 1.1 specification says that only two request objects can be open by a browser simultaneously. IE adhere to this by default (although it can be changed in the registry) while Firefox has a default of eight. Oh well, if this changes in a future release, I'll be ready ;)

Here's what the model looks like for you UML folks out there:



Next, I'll get into some of the implementation details and specific features of the framework.