Why use a database? (data base management systems) (Compute's Getting Started With: Databases)
by Tom Campbell

One of the questions I'm asked most as a computing professional is, Should I get a computer? My answer never varies. If you're getting along fine without a computer, you'd probably end up buying the most expensive doorstop you've ever seen. But if you're doing anything repetitious and error-prone, having trouble maintaining your contact list on the job or running a business in which maintaining inventory records by hand is a problem, you're ready to buy a computer -- and a databased manager.

Database management has long been one of the best reasons to use a computer so much so that the second high-level computer language invented, COBOL, ha sit built in. It's a task uniquely suited to the price-performance ratio a computer represents: Most databases are stored on disk instead of in RAM, yert by its nature disk-based data can be indexed and retrieved so fast that disk storage, while far cheaper than RAM, is nearly as quick. Further, database technology on micros surged ahead of that on mainframes when dBASE II was invented in the 1970s, and it hasn't looked back since.

A database management system, or DBMS (what would any field of study in computing be without a few gratuitious abbreviations tossed in?), lets you store information in tables, a row-and-column format familiar to anyone who's ever signed a guest book or filled out a membership roster.

The list itself is called a table. The rows are usually called records, and the columns are called fields. Sometimes, tables are called databases, but the term database normally encompasses everything that makes up a database application: tables, data entry forms, reports, and so on. If the terminology seems a bit, uh, fluid to you--not to mention maddeningly vague--you're right. Database managers have evolved at a furious rate for the last decade. Mainframe database theory has strongly influenced the development of PC products, but the PC market is a richly varied one and has played host to dozens of products, each of which employs a slightly different vocabulary.

The fastest database managers use two basic tricks to get the best performance out of your computer, and believe--me--they're fast. The first is pretty straightforward: When you design the table, you're asked to specify a maximum size for each field. For example, you might allot 15 characters for the first name, 25 for the last name, 35 for the city, and so on. That way, once the database knows what number the records is, it can position the disk to--or seek, in computerese--that record simply by multiplying the record number by the size of the record. Hard disks can seek anywhere in thousandths of a second; all they need to know is where to go. (For that matter, even floppies are fast enough for most database operations; that's how efficient database managers are.)

The second trick database managers use is indexing. An index is a copy of one or more of the largely in RAM. When you design the database, you're asked which fields you want indexed. While indexing consumers extra disk space and memory, it rewards you handsomely in performance. Microsoft FoxPro's legendary indexing scheme can in some cases search a million records in two or three seconds, but all of the products mentioned here do just fine for anyone with less than 100,000 or so records.

If you read this magazine, chances are you need a database manager. Read on to find out which will best suit your needs.