Volume Number: 16 (2000)
Issue Number: 6
Column Tag: MacTech Online
by Jeff Clites <online@mactech.com>
Earlier this year we covered WebObjects, but we didn't go into detail about the database solutions available to use with it. This month we are going to cover relational databases which run under Mac OS X Server. I should mention up front, though, that it's perfectly possible, and quite common, to run your application server and database on different machines, under different platforms. There can be convenience and speed advantages to running everything on one machine, but as your website scales up to higher capacities, you're certain to reach a point where you need to run multiple copies of your application server, on multiple machines, and modern databases are designed with the expectation that they will be accessed simultaneously from multiple locations. Of course, backing a WebObjects application is only one use for a database, and you may have other reasons for wanting a solution that you can run locally.
I should also explain a little bit about the way that WebObjects interfaces with databases. They communicate through an EOAdaptor, which usually takes the form of a shared library. The adaptor and the rest of the Enterprise Objects Framework (EOF) take care of most of the details of this communication, so that the developer doesn't have to worry about differences between the databases or between the dialects of SQL that they support. (It's even possible to develop adaptors to interface to non-relational databases, and Apple supplies an example Flat File Adaptor which lets you access formatted text files as though they were database tables.) Apple supplies EOAdaptors for Oracle, Sybase, Informix, and ODBC, although not for all platforms on which WebObjects runs. There are third-party adaptors available for many others—all of the databases we'll cover below have adaptors available. Note that there is currently no ODBC EOAdaptor available for Mac OS X Server, because the ODBC libraries aren't available for the platform, and neither are drivers for any of the databases you may wish to access by ODBC. (ODBC, or Open Database Connectivity, is a technology invented by Microsoft, and attempts to allow you to access different databases via a common API, with support for different databases being supplied by ODBC drivers. Its goal is analogous to that of the EOF, although it is functionally quite different.) Third parties have announced that they plan to bring ODBC support to Mac OS X, but it hasn't arrived yet.
You have three main choices if you do want an SQL-based database which runs on Mac OS X Server itself: FrontBase, OpenBase, and MySQL. Each has its advantages and disadvantages, and the best choice will depend on your situation.
OpenBase has had a long history on the OpenStep platform, and was written specifically to run there. It comes with graphical administration tools, and has a few features, such as the ability to notify applications when data changes and integration with REALbasic, which are not commonly found in other databases. Mac OS X Server ships with OpenBase Lite, a free version which allows you to work with the included sample databases, but this version lacks administration tools and isn't really appropriate for development work. There is also a fully functional, time-limited demonstration version which you can download from the OpenBase website. This gives you ample opportunity to try out OpenBase for yourself, but for actual development or deployment you need to obtain a commercial license. Also note that OpenBase is available for Windows NT and Solaris, in addition to Mac OS X Server, so it is a good match for heterogeneous environments in which multiple operating systems are used, or migration from one to another is likely.
FrontBase, produced by Frontline Software of Denmark, is a cross-platform database written in C. It runs on a variety of platforms, including Mac OS X Server, Windows NT, Solaris, and Linux. Like OpenBase, it includes graphical administration tools, allowing you to create and manage databases easily. (Of course, you can also do this using SQL directly.) One key attraction of FrontBase is its flexible licensing terms. There are a number of different levels, based on different degrees of support and different features, such as bulk import tools and the ability to lock tables in memory. The lowest level is free, and is fully functional but lacks security features. This basic version is more than adequate for development work, and can even be used for deployment if you keep it safely behind a firewall.
The third choice is the open source database MySQL. (It's open source, but there is a fee for some types of commercial usage.) MySQL is very popular in the Linux community, and Anjo Krank has created a set of patches which allows it to run under Mac OS X Server. Actually, recent versions of MySQL will compile and run without patching, although you need a pthreads compatibility library which he provides. (He has also developed an EOAdaptor for MySQL, and a Perl DBI driver for FrontBase.) MySQL's claim to fame, other than being open source, is that it is extremely fast. The reason for its speed is, in part, that it lacks certain key database features, such as transactionality and rollback. These are major capabilities to do without, and in fact technically disqualify it from being a relational database, but if you can live with its limitations then it can be an excellent choice for many applications. Due to its heritage, you'll have to survive without built-in graphical management tools, but in the database arena it is often convenient to manage your database directly via SQL, because it allows you to easily save and reuse scripts for common tasks.
As I mentioned before, you can certainly run your database on another platform, even if you are developing for Mac OS X Server. One setup you may want to consider is running Oracle8i under Linux. (This would unfortunately mean running it on an Intel box—Oracle runs neither on Mac OS X Server, nor on LinuxPPC. Given that Larry Ellison sits on Apple's board of directors, there is some hope that this situation may improve in the future. A Darwin version could do amazing things for the platform.) Neither Oracle nor Linux is trivial to administer, but I've heard it argued pretty convincingly that you should use Oracle from the beginning, even if you thing it's more database than you need. The argument goes that if you are running a database-backed website, you will eventually need Oracle, and your life will be easier if you don't have to deal with migrating to, and learning to administer, a new database just when your business is taking off and you're exceeding your capacity. (It's also true that both Linux and Oracle experience looks good on a resume these days.) Oracle is by far the most widely used database on the planet, and it has an excellent reputation for performance and reliability, although it's almost impossible to get hard numbers to quantify this. Personal experience has led me to believe that commercial databases all perform similarly when it comes to raw retrieval speed, although Oracle's unique approach to concurrency control and locking should give it an advantage when many processes are writing to the database at the same time. (In a nutshell, readers and writers rarely interfere with one another.) Oracle also has a very well thought out approach to backup management, and if your database fails you can often recover all the way up to the very last transaction committed. While making your decision, you should be aware that Oracle is extremely expensive, and although its licensing scheme is difficult to decipher, it does appear to be free for development use. If you plan on running a business which will depend on your database, you should give Oracle serious consideration. For extremely high-capacity deployments you will probably want to run Oracle on Solaris, and migrating from Linux to Solaris will be much easier than migrating from a different database architecture. (Oracle has been very good about making its database operate almost identically on all supported platforms.)
Once you've committed to a database, check out the MacTech Online web pages at <www.mactech.com/online/>.
