When DOS 2.0 was brand-new in 1983, I was using Lotus 1-2-3 to maintain a mailing list. It was easier than using EDLIN and the DOS Sort utility, but it still seemed like a clumsy, error-prone approach.
That’s when I decided to get acquainted with my first database package — Microrim’s R:base. My reaction was love at first prompt.
That early experience with R:base gave me some convictions about the proper way to configure a database. Those convictions persist to this day, although I was often forced to use other tools because of a client’s preference.
When I recently had the chance to get reacquainted with R:base 4.0 under OS/2, I was happy to find that an old friend had kept all its good points while adding some useful new features.
I wasn’t aware of my R:base-inspired principles until I ran across other packages that didn’t uphold them. For example, this was quite apparent when I finally had to learn dBASE. It was required by a consulting project that specified the use of the then-new Clipper compiler for low-cost distribution of dBASE applications.
Not a true DBMS
I was dismayed to discover that dBASE, though billed as a database manager, was really just a record-oriented, BASIC-like interpreted language that worked with separate files of data, indices, formats and the like. That’s what it was then and that’s what it still is today.
I was spoiled by R:base, which was ahead of its time in treating a database as a conceptual whole. A database in R:base was — and still is — represented by exactly three files, no matter how many relational tables the database might contain. By contrast, trying to create a dBASE application was a pick-up-sticks exercise of looking through the source code to identify every required file.
Advocates of the dBASE approach might argue that certain tables, such as supplier information, might relate to several different applications — so it makes sense to make the table a separate file so any application can use it. This method ignores the first requirement of a database: to carefully collect and protect data.
When a data table is left to fend for itself in an unguarded file system, who knows what can be done to it by some other well-meaning program? With data in separate files, records are only as safe as the least carefully written application that uses them.
I was spoiled by R:base, which makes data-validation rules an integral part of table definition — not merely a hoped-for feature of every application.
Applications that use the same data should be treated as part of the database, rather than the data being treated as a mere accessory.
But as I said, I didn’t appreciate these niceties of good database practice until I encountered tools that didn’t have them. What made me such a fan of R:base in the first place was the product’s elegant approach to supporting new users who had yet to learn the SQL-like command language.
All you really had to learn was one word, “Prompt.” This put you into a top-level dialog box, which provided a tree of interactive menus, each defined by which database was open and what column it contained.
At each point, you saw a template of the command you were building, which became more complete as you responded to the prompts. Finally, you got the chance to select the menu option “Execute” and see the results.
It was the most painless process I’ve ever seen for learning this kind of thing: novices could quickly learn the simple cases, the advanced users could easily get help with new features, and anyone could use the prompted mode until they were comfortable typing queries on their own.
Today’s OS/2 R:base is multithreaded, fully SQL-compliant and has all sorts of other refinements. To me, though, it’s still that great product that taught me how to do a database 10 years ago, and it still does it better than most.