The lifeblood of any organization is its data. Maybe it is clinical records of new drug trials, bond prices at the close of market, or the current balance of customer accounts. It must be readily available, and it absolutely, positively must be accurate. Otherwise the organization grinds to a halt.
Pumping the data through the organization is a software machine Ð a database engine. It may crank out transactions on a mainframe, purr like a cat across a distributed network, or put-put along on a desktop PC. It provides a central repository for information that can protected, managed, and backed up. It also provides access to the data by users and other programs that need to act on the information.
Database servers all share common functionality. At a minimum, the server runs as a separate program (a process) on a central hardware platform, listening for client requests for data retrieval or manipulation. The server handles multiuser, multitask process scheduling, input and output from a dedicated file space on a hard disk, caching of data to optimize re-sponsiveness, sharing of data among users without conflict, and processing of commands for administration and manipulation of the database.
In this article, we look at industrial-strength database servers Ð programs running on centralized computers that users access over a high-speed network. Most of the servers included in this article support Structured Query Language (SQL), an industry-standard language for communicating between database servers and clients. Unlike a PC-based database management system (DBMS), which usually includes a user interface for accessing and manipulating the data, the database servers described here are designed to work with separate Ð and often custom-built Ð front-end programs. (See "Data Dashboards," NeXTWORLD, February/March 1993, for a survey of NeXTSTEP database front ends and development tools.)
In the early days of NEXTSTEP, users had limited choice among database engines. One of the leading SQL data servers, Sybase, was available to run on NeXT hardware and was bundled for a time with the operating system. Later, the market-leading vendor, Oracle, began shipping a version of its server for NEXTSTEP 2.1.
With the introduction of DBKit in NEXTSTEP 3.0 (see the sidebar, "The NEXTSTEP Connection"), adapters could be easily written for any database engine. NeXT's database strategy is based upon the idea of interoperability: NEXTSTEP works with practically everything. What was once a liability turned into one of NeXT's best assets.
NeXT ships DBKit with adapters for Oracle and Sybase; third parties have developed their own adapters for most of the other well-established and popular commercial data servers, including Gupta SQLBase Server, IBM's DB2 and VSAM (through Micro Decisionware's OS/2 gateway product), Ingres, Borland InterBase, and NCR Teradata. Most of these data-base programs run on dedicated servers (not running NEXTSTEP), which you connect with NEXTSTEP-based computers over a network, although Gupta SQLBase Server and Borland InterBase are both also available in native NEXTSTEP versions. SofDesign Solutions' QuickBase and Blue Rose's Rosebase are NEXTSTEP-only data servers. Although this denies these databases access to fast RISC-based servers now, this should be less of an issue as NeXT's Portable Distributed Object system becomes available on other platforms.
Though the cost of the software itself may be modest, the costs of deploying the system, administering the database, and re-engineering applications used with the system can quickly make the software costs appear insignificant. And since the costs of changing your mind Ð and changing your data server Ð can be momentous, organizations rarely switch from one server to another once the initial purchase is made. Thus, choosing a data server has a lot more in common with choosing an operating system than with choosing an application program.
If you're planning to use NEXTSTEP-based workstations to access information that's already stored on your mainframe or departmental server, chances are that the best database for you right now is the one you're already using. The product sidebars with this article will tell you where to find DBKit adapters for your DBMS.
If you are just now building a new information-management system, the first decision you'll need to make is where you want to run the engine. A variety of servers are available for NEXTSTEP now, which means that you can cut your hardware costs by running the data server on one of your workstations (or your file server). Alternatively, if you are out to replace a mainframe, you might be better off buying a minicomputer or mainframe-class workstation and using the computer just as a data vault. In this case, you can run any operating system you want on the server and connect to it from NEXTSTEP over the network.
In this report, we surveyed users of every relational database-management system that can be used with NEXTSTEP. In our interviews, buyers cited various considerations for differentiating databases, including performance, features, standards, support, and price.
If all else were equal, you could simply choose your data server by looking for the company that offered the best price. And indeed, if your re-quirements are very simple, this may be the only analysis you'll need. For example, you may be developing an uncomplicated application that stores a limited amount of data. In this case, you'll be well served by SofDesign's QuickBase. At a price of $695 for three users, it's the least expensive data server you'll deploy under NEXTSTEP.
Database speed is another primary concern for many purchasers. That's because a slower database engine requires faster hardware to support the same number of users or to answer a query in the same amount of time. Unfortunately, comparing engines is notoriously difficult, since many manufacturers optimize their systems to perform different tasks better than others. Add to the complexity the fact that different servers run on different hardware platforms. Thus, determining the speed of a database is a lot more difficult than calculating the number of pages per minute you can crank out of a laser printer.
The speed of your database also depends on how you will be using it. On-line transaction processing (OLTP) is the traditional forte of the relational data server. Order-entry applications make for classic OLTP Ð clerks write data to the database in repetitive short bursts. If you are going to use your engine to support management applications involving browsing through large data sets, reading, analyzing, and making only occasional updates, you should consider servers that are optimized for on-line complex processing (OLCP).
Database performance is tracked by the Transaction Performance Processing Council (TPC). The TPC is a nonprofit organization funded by a large group of manufacturers of computer and data servers, chartered to disseminate objective performance data. The TPC maintains and publishes a list of all systems that have been tested with standardized benchmarks. The TPC does not run a single benchmark on data engines; rather, it tests database-management systems using several benchmarks, one optimized for OLTP and another for OLCP. TPC reports (available from the council at 408/295-8894) detail how fast each server runs on a particular hardware configuration. Unfortunately, different benchmarks are not always comparable: How do you compare Oracle7 running on a SPARCstation 10 with Ingres running on an HP 700?
Some users may wish to consider the size of the database server. While all servers can handle gigabytes of on-line storage, few can function with less than 10MB or 20MB. The exception is the four data server products that run natively under NEXTSTEP, which all fit neatly in less than 2MB.
Daniel Miles Kehoe is a contributing editor for NeXTWORLD and an associate with the consulting firm Marble Associates. He can be reached at [email protected]. Simson L. Garfinkel is a senior editor at NeXTWORLD. He can be reached at simsong@ nextworld.com.