Databases

This article will continue a mini-expedition of sorts through the abundance of offerings found in Linux. Last month I gave a rough accounting of spreadsheets and text editors available. The listing was nowhere near complete and was almost certainly out-of-date by printing time. The same caveat will apply here as well.

My new fountain for material is Infomagic's four-CD Linux Developer's Resource—Live Slackware, mirrors of Tsx-11, Sunsite, GNU archives, and a variety of other topics.

It's easy to get lost in the CD maze of Linux programs and my glasses are already thick from too many hours in front of a computer. The following is not meant to be a definitive listing, just a gentle survey of some of what is available.

As I did in last month's column, I want to stress that the following products are not commercial, although be commercial versions may be available. Also, let me state my expectations to make you are aware of my viewpoint. As a DOS database enthusiast, I expect many of the Linux database offerings to be on par with, say, a dBase II or dBase III, and perhaps compatible with them. Kind of like what I found with the spreadsheets being on par with early versions of Lotus-123 or Excel. Also, I hope for an interface nicer than the infamous dBase dot-prompt.

The term “relational databases” refers to a way of “joining” databases based on common (and usually indexed) fields. For example, a physician database might link to a patient database with the common field of physician ID appearing in both. When you choose a physician (thereby also setting an ID) all of the patients with the same physician ID will be also be selected. Not the best example, but it conveys the idea.

Take a deep breath, and onward.

mbase (v5.0) is a relational database system originally written for the Amiga and ported to other platforms. It uses a C-like format to do the database programming and, unfortunately, that's as far as I could go with it. To compile required ncurses which I installed but apparently not into the directories expected by the mbase Makefile. Editing the Makefile didn't help much either. mbase is beyond this novice, at least setting it up is. I don't think mbase will meet my expectation for a friendly interface if it uses a C format. As a final punch, when I removed ncurses Linux started to behave weirdly. Strange, since I used the installpkg and removepkg utilities included in Slackware and they're pretty reliable (assuming they are the problem). I reinstalled ncurses and now Linux is happy. [ncurses is becoming the standard for Linux, which should make some of these problems go away. For more information on ncurses, see page [??]--Ed]

lincks (v2.2 pl 1) is an OODBMS or object oriented database management system. It's covered in the March, 1995 issue of Linux Journal, but I made the mistake of not reading the article before installing. Consequently I gave up in frustration after a very short time, confused over trying to get the RPC portmapper to portmap. I'll stop here and refer people interested in lincks to the afore-mentioned article. However a thought flashed through my head: I'm looking for a single-user type database system and many of these are multi-user, client-server Leviathans. I have an inkling that many more won't work because they expect some sort of network.

onyx (v2.24), a database prototyping program, is also based on C-like language. It was reviewed by the program author, Michael Kraeh, in the very first issue of Linux Journal, March, 1994. Single users can use it as a database program, I guess, but I wasn't able to use it. The documentation didn't explicitly say how to compile or how to get started, quite an annoyance for this novice. I did figure out that make config would start the process, and a nice structured series of questions popped up. These questions would configure onyx but nowhere is there help as to what they refer to. I wasn't surprised when it bombed. With the swap file active I tried a make all install which ground for awhile but accomplished nothing. I took a final glance through the various files using mc as my snooping instrument but discovered nothing to help. Since onyx is still a work in progress like many Linux programs, I continued on to the next offering.

postgres (v4.0.1a) and Ingres (v8.9) I'm lumping together. Both are apparently high-end, multi-user, client-server systems. Both have installations that stumped me because I'm a single user and didn't install any network programs. Ingres, to make things tough, recommends looking in setup.doc for installing instructions. Guess which file didn't exist? While neither of these of packages will meet my xBase expectations for ease (I'm guessing on this), I do hope that an expert with some free minutes will write a couple of in-depth articles on how to use both of these programs. I heard of postgres and Ingres even before fiddling with Unix so I'm curious about them. [There is a relatively new project to create “Postgres 95”, which is intended to be a more modern, bug-fixed version of postgres. It should also be easier to build than the old “University postgres”—Ed]

pfl (0.2 alpha) untars nicely but the doinst.sh script didn't work for me. According to the documentation, pfl is similar to Lisp which tells me that this may not be suitable for impressionable novices and certainly not what I'm looking for in an easy to use program. That is, I doubt it's xBase compatible.

qddb (1.41.3 beta) stands for “Quick and Dirty Database”. It's a database development system that uses but doesn't require Tcl. However it does require bison 1.22 and flex 2.4.1 to compile. After so many packages my heart is beginning to fade. I admit I looked at what it takes to configure this package and didn't even give it a try. It looks that scary and something tells me qddb won't be what I have been expecting anyway. Yes, I'm being an outright wimp.

DBF (1.5) calls itself the x-base manipulation package and surprisingly (after so many novice failures) it actually worked for me. It's a small collection of programs that manipulate dbf files. For example, dbfadd adds a record or layer of information to a database. dbflst lists the records in a database. dbftst lists the structure. And there are other such utilities. I wouldn't want to manage a complicated database system with this package but for quick and easy fiddling with a dbf file, it works, and the programs don't take up much hard drive space.

typhoon (1.06) is another relational database system. One of the text files states that it was a rush job meaning incomplete documentation to make poor novices sweat. I liked the honesty and hated the reality. Like many of the previous database packages, it just wouldn't compile correctly. The process takes two steps. The first, configure, runs cleanly. The second, make, crashes with some sort of menu. I tried make all and make install, both under /usr and /usr/local, but to no avail. I may go back for another try after fiddling with some of the other packages because typhoon was inspired by Raima's db_VISTA, a system I'd like to try. I assume the one major difference between this and db_VISTA is the C structure for all processes. typhoon, according to its literature, can handle a variety of unions, relation keys, and variable types. Referential integrity is also part of a good list of features. The author is currently working on, among other things, import and export functions. It all sounds impressive! If it would only compile for me.

FlagShip is a good-for-10-days demo and reading some of the docs gave me great hopes and familiar ground to explore. It offered CA/Clipper and dBase compatibility, an ability to include C code and with included utilities can even access FoxPro programs and databases! Could this be my Grail achieved? It started out easy enough. Copy the multi-meg fs4lix.gz1 and .gz2 to /tmp/FS and concatenate them together with:

cat fs4lix.gz* > fsdemo.tar.gz

After that I ran FSinstall which walked me through a menu. And then my luck failed. The program did something to my screen so that I couldn't see what I was typing; rebooting cleared the problem. Going to /usr/FSsrc, I compiled a sample program successfully but the result was a file called a.out which again killed my screen when I tried to run it. Fine, maybe FlagShip is expecting to run under X-Windows. Delete a.out, set the swapfile active, into X-Windows, compile another test program and, yup!, another a.out which weirds up the system. Luckily, exiting X-Windows restored things. Perhaps it may be the ncurses that I previously installed for mbase. FlagShip seems to want a different version of curses and unfortunately I don't have the know-how to test this idea.

Farewell to FlagShip. At least the package includes a useful though tedious FSuninstall. It asks you for every single FlagShip-related file whether you want to delete it. 2.9 billion prompts for deletion or it felt that way after awhile. But of all the programs I looked at, FlagShip held the most interest for me as a visitor from DOS and probably would be what I would purchase if I needed a Unix database system. Of course, I would have someone else install it.

My expectations for something familiar weren't met. None of the packages looked like a dBase clone except for FlagShip which I never got to any sort of visual state. Yet where I was expecting an immature field it looks or sounds like these programs are fairly sophisticated (although quite a chore to compile and install).

But unmet expectations weren't the frustration. It was the general lack of success. I make an effort for this column to end with some sort of achievement. Sure, I may end up re-installing Linux twelve times, but always I've ended positively as a sort of morale boost for us intrepid novices. Not this time. Except for the DBF set of xbase utilities, this Casey struck out, overwhelmed by intense installation instructions.

What also bothered me is that many of the packages—and I am not just referring to databases—lack decent documentation. For a novice, two crucial items of information are where to unzip, uncompress, or untar the packages and how to compile, particularly if the Makefile requires or expects things in a certain way. I applaud the “.lsm” files which accompany many zipped and compressed files on the CDs and on the Net. They give some help in figuring out what goes where before you actually unzip.

I can hear some of the software authors saying “So what? The hackers, the experts can figure things out,” and this may be true. But Linux has been getting great reviews and mentions in many popular and diverse magazines, and with that you're going to get people other than experts snooping around and wondering, “Why the uproar?” These people represent the future audience of Linux and like it or not, these Linux novices will have to be attended to in terms of easier installation routines and clearer documentation. It's part of the price of success!

Next month: more mischief and a happy ending.