True Client/Server environment.

Some of the little products have claimed they are much faster than Interbase and SqlServer. Contrarily, in the "big dogs' fighting", Interbase is never mentioned. So, are you reading about the worst database product when compared with both tiny and huge RDBMS systems in the world? I want to give you a perspective to let you decide if IB is worth a try.

First, let me say that when you stare at the tiny engines that claim to be SQL databases, if you are not familiar with the C/S concepts, the most common SQL commands and the requirements for a database to be called with justice "relational engine", then you should read some generic documentation before doing your decision. Some of the little engines that claim to be SQL engines in fact support the SQL language, but this doesn't suffice to be a relational server. Some of these small products don't have transactions, don't have good and safe concurrency control and are designed with only one user in mind. If they allow multiple users, be sure to check which are the restrictions, because you may be entering into a dead end. You have to check which features each one of them offers. With those features not implemented, it wouldn't be a great surprise they are able to beat SqlServer, for example. If a product is so simple, perhaps you are better with Paradox and still the Paradox engine built into the Borland Database Engine will let you use not too complicated SQL sentences. The need for transaction arises in every serious application when you must make a set of commands an atomic action that gets executed completely or is undone completely. Also, transactions are key to avoid other users from seeing your uncompleted changes. This is one of the traditional problems with Paradox, for example. IB has all features needed to deserve the name of SQL database and even more, it's a relational database compliant with SQL92 if not 100%, at least at a good degree.

Second, when you lurk into the enterprise market, products like SqlServer and Oracle submit benchmarks to the Transaction Processing Performance Council (TPC Organization) using the rules this organization has. These benchmarks use an idyllic, unnatural environment to test. There's no safe way of making comparison in real life scenarios. See the history of the TCP benchmarks for more information. However, they're a scientific measure of the raw power of a RDBMS product and they provide an objective means of comparing performance and performance/price of different system. I'm not underestimating these benchmarks' results! Without TCP, every vendor could make any fantastic claim in a marketing campaign. Usually the members compete to see what company's product is able to do more operations per second and at which monetary cost. For this to happen, these giant database systems usually are turned into single user mode, meaning they can forget about locks, concurrent transactions and other features that exist in the real world. Interbase can't compete here. It's query scheduler (or optimizer) is not so well optimized as the most known relational database systems. Usually, you have to help, designing with care your query sentence if it's complex so the optimizer can get the best of it. IB's tests on inserting million of records in the least time period possible in single user mode do not shine when compared with Oracle, but informal tests done by users seem to indicate the loss of performance is not very important when weighted against the special features in IB and the big difference in price.

If you need a database mainly for OLAP, then probably you should look elsewhere. The results won't come with the speed of NCR's Teradata, for example. And nobody knows an IB database using more than 300 GB. Also, the multi version engine would take a noticeable amount of space to keep records' versions in a database that grew above 400 GB.

Conversely, if you need a database for OLTP, then probably IB is a good decision. IB is not optimized to handle laboratory's cases but to handle real life cases. In an environment with high concurrency and data volatility where at the same time there are people who need accurate and consistent reports, IB shines like no other commercial RDBMS. In real cases, there are users trying to see the same record while other user is changing it and there are users interested to get a report that shows a consistent view of the data, so the numerical values match as expected in different categories of the report. Also, there may be users trying to run a complex process that requires multi passes over the same tables and records and always they must be able to see the same data. Interbase comes in handy to fulfill these requirements. Other engines cannot prevent locking among users viewing and users altering the same data. Surely, any decent enterprise-class database engine can keep a steady view of the data while other transactions take place, but at a high cost in performance and expect some locking headaches to appear, because best known RDBMS products are normal relational engines, not multi version engines like IB. With Interbase, these operations are natural, because it's the way the engine was designed, so it's working in the same internal mode always.

As you can see, no model of an engine is perfect. It all depends upon the type of task you have as your primary priority. Probably, a good compromise would be having IB handling the day-to-day operations in real time (avoiding unnecessary locking) and feeding a powerful OLAP-optimized server with the committed data so the CEO and the directors can have their decision cube in record time, thanks to (perhaps) a solid query and other tricks.

This page was last updated on 2000-05-26 04:28:46