I’m not coming up with a great topic for today, so I thought I would share a few of the many relational database engines I have used over the years. I started working with relational database engines while I was in college. I took a course for relational databases that used engines running on the old DEC PDP-11 computers called Bloom and Harvest. Both were written in Fortran and resembled a combined syntax of Cobol, Dbase and SQL. They were really cool but didn’t really catch on.
I moved to the PC based database engines for a few years, working on decision support applications. This was a great place to be in large companies. I was a favorite with managers and executives because the backlog was too long to get things in place on the big iron. So, I worked with a number of dbase like engines for quite a while. Dbase II & III, foxpro, vpInfo and Clipper all fell into this category and worked great for small applications.
Of course there was the foray into the Mac world where the databases were not so much coded with syntax. Instead they were based on forms and wizards to build your database constructs and screens using products such as Omnis, or Hypercard.
I ended up working with RBase using the RBase implementation of SQL (which was quite rich), MS Access using jet SQL, and Power Builder using Watcom (which is now Sybase SQL Anywhere) or SQL Server.
By this time it was 1993, and I had moved into consulting where I had the opportunities to work heavily with SQL Server, and later with DB2, Oracle, MySql, and dabble in Informix. In all of this SQL Server has been my favorite platform. I find it to have great value for the price, although that diminishes with each new release. Not to say that the value isn’t going up; I find the tasks I am working on don’t really take advantage of the new features as much as I would like. I guess the problem is that they have built a really powerful engine that can, at the lowest level, perform some amazing things.
Here are some of the things I find common with all of these different data engines.
- You really need to understand the process of data normalization to get maximum performance out of these engines.
- Indexing is essential to the performance of the engine.
- You can reduce contention by knowing the data usage patterns of your database and design the schema and access around those patterns.
The thing that I find interesting about all of these engines is that SQL is the dominant factor in survival. All of the engines I mentioned above that support SQL are still alive in some form today. That doesn’t mean they couldn’t be accessed using ODBC as an SQL interpreter. I’m saying that they had some native implementation of SQL. I wonder what we’ll see in the NoSql engines in a few years. Already there is movement to create SQL interfaces into NoSql engines. Who knows?
Cheers,
Ben