Introduction to the Firebird Database
In the open-source world, much has been made about the need for a full-featured, robust and reliable database that can handle substantial loads and yet be able to play well with such open-source tools as Perl and PHP. The two main contenders are PostgreSQL and MySQL, but a new arrival in this arena is the Firebird RDBMS. It offers a substantial feature set, a mature code base and a proven track record in its previous incarnation as the Borland InterBase RDBMS. As discussed later in this article, Firebird provides a lot of the features available in commercial databases, including stored procedures, triggers, hot backups (backups while the database is running) and replication. As with many mature products, Firebird carries some amount of legacy baggage, which can be a bit confusing to a new user. So before we plunge into exploring the features this database provides, let us look at some common issues that may confront a new user.
Firebird originally started its life as the Borland InterBase database. As the product reached version 6.0, Borland decided Borland the product was going to be aged out, and so the code was released under an open-source license. Later on, however, Borland apparently had a change of mind about aging out the product. To this day, internally, Borland continues to develop the InterBase database, with the latest version being 7.1. Firebird 1.0 essentially was the open-source code behind InterBase 6.0. As of this writing, the first major development effort of the Firebird branch is Firebird 1.5.
For the new user, Firebird has two confusing aspects. First, the database is available in two flavors; second, various flavors of SQL dialects can be used, each carrying its own implications. Let's first look at the architecture issue and then move on to the SQL dialects as they relate to Firebird SQL.
As noted, the Firebird database comes in two variations, classic server and super server. Classic server is the original architecture behind the database. In the classic architecture, a separate process is spawned off for every connection made to the database, with the help of the inetd or the xinted dæmon. When there are few database connections, classic server uses less resources than does the super server architecture.
The super server architecture has been slated as the future direction in which the Firebird database will develop. It is a multi-threaded, multi-client architecture that requires few resources when additional connections are spawned off. Resource allocation and lock management are much more efficient in the super server architecture, because separate processes do not have to wait for others to finish before they can be addressed. One issue for the programmer to take into consideration when writing against a super server is any user-defined functions, including any external program that interacts with the super server database, needs to be thread safe. For those familiar with Oracle's architecture, an easy way to look at the connections' allocation is that classic is akin to dedicated connections while super server is more like the shared connection allocation system. For more information on this topic see the Resources section.
Another aspect of this database that might confuse the new user is the three separate dialects of SQL that Firebird offers. Dialects pertain mostly to the date-time format and the precision of a numerical data type. A good rule of thumb: if you are not familiar with the different dialects of Firebird, go with dialect 3. This dialect not only conforms closely to the latest ANSI SQL specification, it also should be familiar to users of Sybase and MySQL. Dialects are set up at runtime and can be changed for the client at connection time or with a set sql dialect command.
As the super server is the future direction of the Firebird database, this article concentrates on super server as the architecture of choice. As of this writing, the release candidate for Firebird 1.5 was available only in a binary tar, bz2 format. Unfortunately, no formal documentation is available for the installation of this, so here is the installation in a nutshell.
To install this tar file, bunzip the file and, as root, untar it in /usr/local directory. This creates the /usr/local/firebird directory. If you want the database to start by default at boot-up, run the minitinstall.sh scripts in the /usr/local/firebird directory. Otherwise, run the firebird.initd:
# sh ./firebird.initd start
By default, the database runs on port 3050. The binary used for this article took the libstdc++5.so, which is available with glibc 3.2, so make sure it is available. Also, add /usr/local/firebird/lib in /etc/ld.so.conf and then run ldconfig so the system can look inside that directory for the libraries. Finally, many third-party tools (Perl, PHP and so on) look in libgds.so for client communication purposes; this file does not exist in super server. The workaround I found involves putting a soft link from libgds.so to libfbclient.so, which seems to satisfy the applications.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Profiles and RC Files
- Astronomy for KDE
- Understanding Ceph and Its Place in the Market
- Maru OS Brings Debian to Your Phone
- OpenSwitch Finds a New Home
- Git 2.9 Released
- SoftMaker FreeOffice
- What's Our Next Fight?
- The Giant Zero, Part 0.x
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide