InterBase is, and continues to be, one of the hidden gems of the relational database world.
From its inception in the early 1980s, through mainstream adoption and evolution under Borland, InterBase looks back at a track-record that spand decades; at times defining the standard that all other databases were measured against.
With Embarcadero acquiring the Borland development portfolio in 2008, InterBase has again been brought up to speed with the latest technological advances; surpassing them even with features like Change Views.
Thanks to steadily refactoring and evolution since Embarcadero took over; its performance and scope have seen radical performance gains. Once again InterBase is the cutting edge, synonymous with performance, security and platform diversity.
The optimizations invested in our gentle giant over the past eight years alone are too many to list. Embarcadero has done an amazing job on modernizing this much loved — and dare I say, archetypal relational database. At the same time, they have managed to retain the functionality that is quintessentially InterBase: Features that set the product apart.
For an old Delphi developer like myself, using InterBase in my production environment again is an emotional experience. InterBase was part of my university curriculum and used in my first commercial software development alongside Delphi.
Familiar yet unmistakably modern, fresh yet mature and established.
I want to present five good reasons why InterBase should be your next database. Writing about a subject I am passionate form easily turns into a novel, which is why I am limiting the features to a modest five.
Let’s jump in and look at why should InterBase 2020 be your next database?
Table of Contents
1: Platform Diversity
The world of technology has changed dramatically in a very short time. The way that technology evolves, be it software or hardware, is typically through sudden, unexpected leaps. The mobile revolution of 2007 spearheaded by Steve Jobs, as he unveiled the iPhone at the Apple developer conference in San Francisco, was one such leap.
Overnight, the criteria for software development were irrevocably changed.
Fast forward to 2020 and two-thirds of the planet’s population are walking around with a proverbial super-computer in our pockets. Each filled with applications, ever-growing in complexity, and with a very real need for reliable data persistence.
Today business is conducted more and more on mobile devices, and with that, the ability to deploy software to different platforms, operating systems and hardware is a necessity. Multi-platform computing is now the prerequisite that all developers, regardless of programming language, must base their strategy on.
When you need multi-platform support, InterBase is a pioneer and ahead of its time.
Already in the late 80s, InterBase was available for a variety of computer systems; from large and powerful business machines running Unix, to more modest home computers like the Apollo or the Commodore Amiga.
The targets of 2020 are very different, but InterBase remains the same versatile and platform-independent database system that it has always been. Today, it can be deployed to all leading platforms and operating systems: Windows, Linux, macOS, Android, and iOS. InterBase also supports heterogeneous OS connectivity across all supported platforms.
The ability to use the same database on multiple architectures is by far my favorite feature. It saves time, reduces cost, and makes life significantly easier during maintenance.
Internet of Things
With the advent of the Internet of Things (IoT), embedded computing went through a remarkable transformation. One that is closely related with the mobile phone revolution and related to our coverage here.
Embedded computing used to be a specialized niche in the marketplace. A niche more or less dominated by electrical engineers. But as the mobile phone revolution stimulated mass production of affordable CPUs, chipsets, and SoC (system on a chip), it was only a matter of time before someone would assemble a new style of embedded board. And in 2012 that is exactly what happened. The $35 Raspberry Pi minicomputer became a reality, and with it — embedded became a household name.
Since this new class of embedded boards is made from the same parts as mobile phones and tablets, they also have a level of performance that makes them interesting for the consumer market. They have the same CPUs, they run the same operating systems (Android) — which also means that they can run the same software.
This is where InterBase comes in.
Creating solutions that also include hardware is one of the most exciting aspects of software development. InterBase covers a wide range of embedded devices (ARM and x86) — IoT boards and mobile phones are ultimately just different configurations of the same parts.
And on such small devices, the need for a fast, reliable and secure database is very important.
Thankfully, InterBase has you covered.
2: Change Views
One of the features unique to InterBase is the way it handles notification and feedback. InterBase has several mechanisms for developers to be informed about alterations in the data, without a doubt, the most powerful of these is Change Views.
Unlike an ordinary database view, a Change View is based on a data subscription model. You define the criteria for the changes you want to be informed about, and once defined you query the database “what has changed since the last time we spoke?”
The impact on things like network connectivity and payload is immediate. Especially true when you operate with a cluster of databases that offers the same data for different targets (e.g web application vs. mobile application), relying on caching in the middleware.
Instead of manually polling a fixed set of rows to update your cache, the most typical technique for middleware, Change Views only fetches what has changed. Your service starts by polling a full set of rows, a keyframe if you wish. Once populated, only the changes are fetched in the future.
When used in a data-intensive system, Change Views have a tremendous impact on performance and responsiveness.
3: Tablespaces
The great thing about a mature database engine is that you have options available for scenarios you might never have thought about. A database engine used in a production environment for decades has accumulated a wealth of experience that can and will benefit the end-user and developer. There is a depth and substance in this that some of the “louder” database systems fail to deliver.
Tablespaces are an aspect of data management that exists outside the table structure a developer would normally deal with. It falls more into the category of management and advanced administration. The overall concept is easy enough to understand and take height for, especially if you are making software that could potentially grow far beyond your initial plans (as it always does!)
Through tablespaces, a database administrator reorganizes where tables and indexes are physically stored in the database files. This gets really interesting when you are managing a 20-terabyte database, accessed 24/7, by 4000 active users. Being able to delegate your authentication data (fields like username, password hash, etc.) to an SSD disk, holds serious merit for performance.
An improvement of even a few milliseconds on each operation, when you multiply that by the number of queries you execute per hour, amounts to a small eternity in computing terms.
Features like this make excellent sense for online businesses that operate with a web-based storefront. Research tells us that the average time a potential customer will tolerate delays before going elsewhere is measured in seconds. Being able to tweak data performance on filesystem level is impressive and welcome.
4: UDF Native Functions
UDF is short for “user-defined functions”, and it’s a simple and elegant way for developers to expand the capability of their queries. In many ways, you can look at UDFs as a type of native plugin.
While not new, UDFs have been a part of the InterBase API for a long time. They are one of those features that helps make InterBase incredibly versatile and popular. Writing an article on InterBase without mentioning UDFs would be unthinkable.
A UDF is a normal native library (e.g. DLL) where developers implement whatever functions they need. Once loaded into InterBase, you can use those functions side-by-side with the standard-compliant SQL functions.
This opens up some interesting data-processing opportunities. Blob data can be offloaded to a native function for processing before it’s issued to its destination. It doesn’t take a major leap of the imagination to see how UDF’s coupled with Web Technology gives developers the building blocks to assemble a system en-par with Oracle PL/SQL, but without the limitations and cost.
Real-Life Implication of UDFs
I spent several years as a developer for the Norwegian government. When I eventually ventured off into the private sector, I was offered a position with what is the biggest supplier of medical software in Scandinavia.
The rules and regulations surrounding accessing and viewing medical documents of a personal and sensitive nature are understandably extremely rigid. What may not be so well-known, is that InterBase has been (and remains to this day) the backbone of the most widely deployed medical system in the region.
Part of that choice was based purely on the fact that InterBase allows developers to expand and interface directly with the database engine on a low level. Besides the industry-standard security InterBase delivers out of the box — UDFs were created for encrypting scanned medical documents — making the data useless outside the ecosystem.
I have yet to find a database engine that makes this level of customization so straight forward.
5: Security
Embarcadero introduced enterprise level (AES) encryption with the release of InterBase 2009. Most database engines operate with binary read/write encryption on file level, meaning that the data pages that make up your database file(s) are encrypted and decrypted as they are written and read.
But InterBase also supports a second level of security. And you can choose to apply one or both in your deployment strategy.
- Database Level Encryption
- Column Level Encryption
Database Level Encryption
Like I mentioned briefly, this is the most common type of encryption that applies a cipher to the data pages that make up your storage file.
Column Level Encryption
As the name implies this is a strategy for protecting the actual database columns. It’s important to underline that this encryption strategy is separate from database-level encryption, adding an extra layer of security.
Cipher Support
InterBase supports two ciphers. You have the older industry-standard DES algorithm. This is a weaker form of encryption suitable for non-confidential data. It has the advantage of not requiring a separate licensing.
AES is the second encryption type. It was adopted as a US federal standard back in 2002. AES enables a larger number of bits with which to scrambled data than DES does. The United States regulates the export of AES because of its strength.
Read more about the AES encryption standard and regulations.
Find more in-depth information on InterBase and its encryption models.
Reflections
I could easily fill a book with good reasons why InterBase rocks. Limiting the coverage to a modest five was challenging. InterBase represents a rich legacy of excellence that spans decades combined with continued innovation that never stops moving it forward. I find myself wanting to add more and more, just to get the message across.
The only way to become familiar with InterBase is to spend some time with it. If you’ve read this far, clearly you find InterBase interesting. You owe it to yourself to download a trial and take a closer look! If you are returning to Delphi or C++Builder, catch up on the awesome new features RAD Studio offers.
Check out the more in-depth information about InterBase on the product website
Thank you for your time!
Design. Code. Compile. Deploy.
Start Free Trial Upgrade Today
Free Delphi Community Edition Free C++Builder Community Edition
Interbase was never available for the Commodore Amiga. The “InterBase” for Amiga was the database component of the “InterOffice” office suite.