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