Editorials

When the Business Can’t Wait-Your Too Late!

I’ve seen many different systems that began as a solution for an immediate need. All of them were based on a simplified, integrated programming platform that encapsulated the storage engine and the user experience. In short, it was often used like a glorified spreadsheet with limited understanding of how applications are designed. There were a lot of issues that resulted from this process. I’m not saying that they made a mistake to do what they did. I am saying that the lack of some fundamental understanding of how applications are designed had negative effects; especially as their product gained success.

Microsoft Access or Borland Paradox were very popular in the early ‘90s because it was inexpensive, and the programs provided lots of customization without understanding how the applications worked internally You could record simply macros to make forms open or close, navigate through an application, build Menus, and much more. They integrated directly with their own proprietary database engine, and had graphical database design tools to simplify table creation for users.

What they could not provide in their application was an understanding of database normalization processes. So, users created tables looking much the same as the spreadsheets they used before these tools came out. Now they experienced a lot of problems with dirty data, extra work to keep data clean, or even enter it. There was additional work to retrieve data because it wasn’t stored in a way that was easily consumed.

To be fair, everything was really pretty. The report tools were stellar. The problem is that the tool could not replace an understanding of how to put together an application any more that the tools we use today can. You still need to be a student of creating applications in order to have a good product.

These applications were not built because people wanted to be programmers. They were most often built because people couldn’t wait for the programmers to get to it. Their success was often their downfall. Other people would see this really great tool, and want to have it too. So, they would put the database on a network file server. And, the database would become corrupted every time someone’s computer lost a connection while using the application. Or, the database would slow down due to fragmentation, or contention from too many users. FoxPro was one of the few file share databases that could successfully handle high volumes without issues. But, it was harder to produce user screens, etc. and was less popular.

With the explosion of Client/Server it was then the idea that we could move off the native database engine and use a dedicated server based SQL Engine. We could connect through JDBC, ODBC, or some native library that would talk with the database service. We quickly found that the tools we had written earlier didn’t work in a client/server implementation. We had lots of locking, blocking, and dirty data issues, because the user experience tools expected real time locking on the records opened in forms.

In summary, we had many of the following issues arise:

  • Poor performance
  • Dirty Data
  • Corrupted Data
  • Application Failure
  • Blocking, Locking, Deadlocking, Server rejection

Although these kind of tools are still around today in some form or another, they have lost popularity to some degree, while some new tools are beginning to emerge.

Why not share one of your history lessons for us. This is such a common experience, I’m sure many of you have a story or two you can share. Just leave a comment.

Cheers,

Ben

Facebooktwittergoogle_plusredditpinterestlinkedinmail
  • Eilenblogger

    I started a new job in 1998ish and the company used Oracle back end for the database.

    I was asked to look at a process that was taking all night to run. It provided some management reports that they needed in the morning.

    So I strolled over to the guy who had written the code that ran all night to get some insight as to what he was trying to accomplish.

    Nice guy, came up through the ranks of spreadsheets and Access, etc.

    The code fetched records from a lookup table and generated some SQL that was a UNION of all the data from various tables with each instance of the lookup.

    So I put a breakpoint after the code that generated the SQL.

    I began to scroll down, down, down, down. You get the picture.

    So this dynamically generated UNION was sent off to Oracle to produce a result (keep in mind this is late 90’s). I was in awe that Oracle would even successfully finish the query albeit that it took all night.

    So I ripped out that logic that generated the UNIONs and replaced it with an inner join to the lookup table.

    The new “process” then took 5 minutes.

    Man it was easy to be a hero in those days. In fact it’s still easy because there are a lot of VERY good developers whose brains dont work so well in database land.

    Now those VERY good developers have got their grubby little hands all over Linq.

    Same as it ever was
    Same as it ever was

  • Mark Anderson

    I’m more interested in what RAD tools are available today. I thought LightSwtich was great and just looking at RadZen