Follow me on Twitter!

    Tips of the day:


    Monday, October 31, 2011

    Database applications

      Traditionally, developing and maintaining database applications has been a time-consuming and frustrating process. A good friend of mine discovered this several years ago, when she worked for a Fortune 500 company with its headquarters in New Jersey and 15 plants across the U. S. She was the Billing Manager at one of the plants, a title which also encompassed responsibilities for system operations. When a new, more powerful system was installed, it was expected that there would be a few bugs in the database driven website. What no one was prepared for was how long it would take to make even simple changes to the database driven website. First, a request had to be sent to corporate, who had to make the change on their system and then download the update to each and every plant before it would take effect. The average time was about two weeks—that is, if it was a very minor fix. Sound familiar? One of the first things my friend noticed when the new system went live was that, for reasons unknown, the names of the freight lines were being severely truncated on the invoices, despite the fact that the fields were properly sized. This wouldn’t have been so bad, except that three of their most used carriers printed out as obscene or highly questionable words on the invoices. Since the information on carriers was entered at the corporate level so it could be tied to various tariffs, rate schedules, and payables, there was no alternative except to send out the invoices as they stood, four letter words and all, for the two months it took to get the problem fixed and the update deployed. During the same time frame, some plants were already running out of room on their local servers. Others were experiencing extremely slow performance, due to increasing the number of users to handle a sudden surge in business. Daily activity was sent by modem to corporate, but because it took longer than had been anticipated, most attempts failed on the first few attempts. Such problems were not all that uncommon during that era. Programmers developed databases in a vacuum, working on stand-alone machines without live data. Once they tried to deploy applications in the real world, in real time, all the bugs came scurrying out and threatened to devour the IT department. And, until cloud computing, there was not a lot of improvement. Moving your database application development to the cloud offers you several advantages. You don’t need to replicate or synchronize databases on various servers, because everyone is accessing the same program. Changes or updates can be made without the delay time necessary to distribute them to all users.