Whilst clearing out the loft recently, I came across some manuals for Prime INFORMATION which was a database management system I did some work with many years ago. INFORMATION was a dbms which ran on Prime Computers (minicomputers) and was what we were using before we graduated up to the likes of Paradox and Access, if you can call that a graduation.

INFORMATION was a clone of a database implementation called ‘Pick’. There are many variants – some of which are still around today, but all have the same central concepts:

  • multivalued fields: It is possible to hold multiple occurrences of the same data item in the same field (assuming of the course the field was created as ‘multivalued’).
  • associations: fields that should always be populated together as a group, and would generally be retrieved or processed as a single ‘entity’ can be defined as such, which helps to give them some additional meaning.
  • fields in a table (or file) can represent either actual physical data (called ‘D’ types) or derived or computed data (called ‘I-descriptors’) which enable the field to contain the results of a calculation. This calculation might be operating on fields in that particular table/file, or can be operating on fields in entirely different tables/files. If you wanted, say, to display an employee’s workplace location (which you might have to get to by joining to the relevant reference data) you would do this in INFORMATION by creating a field with a ‘location’ containing some code that would join to the relevant table and/or perform the necessary calculation and provide the result you wanted.
All very non-relational, of course.

The idea of mini and mainframe computers always seemed rather exciting and glamorous to me, and Prime INFORMATION also held it’s own attractions. For one thing it seemed to actually mirror the real world, in terms of how data was structured. This always appealed to me, and despite spending subsequent years working with relational databases, the Pick approach, just seemed more logical somehow.

Lets have a look at how data is held in an INFORMATION file, based on an example in the manual. Each file (analogous with a relational ‘table’, or ‘entity’) is described by a data dictionary file, which can be queried and updated using the same language and editor that you use for generating queries or writing updates.

An INFORMATION data dictionary

An INFORMATION data dictionary

In this example, the command LIST DICT EMPLOYEES has been executed to list the dictionary of the employee file. We can see that the file contains various fields of different types.

The dictionary has 7 columns:

  • Field Name: self explanatory really, but is the internal, unique field name;
  • Type: as described
  • Location: position in the file, or the calculation that needs to be performed to retrive the data
  • Conv: Any conversion to be performed. From memory I think this is very similar to data type
  • Display Name: self explanatory – simply an alias, but you cannot refer to this in queries
  • Format: Alignment etc.
  • SM: Whether the field is single or multi valued

In the example, the first 5 fields are data fields (‘D’ types) representing phyical data that has been entered. These have a location of 0-4 merely identifying their position in the file. Note that number 2 – FNAME is multivalued, which make sense as employees can have several first names. The currency fields SALARY and MTH.SALARY have conversions applied, presumably to define them as numeric. The last 4 fields are interesting. FULLNAME has some code as it’s location and is simply concattenating the full and last names together. JOB.GRADE contains code that is going to a different file and retrieving the grade based on the Job title that has been entered.

The following gives some simple examples of queries:Query example

Query example

Lets look at some more examples of the command syntax for simple queries:

Query syntax example

Query syntax example

And some more advanced examples, working with multi-valued fields:

Multivalued fields

Multivalued fields

Arrr.. the memories.

This approach to database management always appealed to me, and as I mentioned earlier, it just seems to make intuitive sense. It’s also worth remembering that the proponents of such databases always claimed that concepts such as multivalued fields and so on reflected the ‘true state of nature’: people do have more than one phone number or more than one first name and these aren’t separate fields (or detail rows in another table) but genuine multiple instances of the same value in one field. The structure allows you to have a master-detail relationship in the same record, which is incredibly powerful. The concept of fields consisting of derived data, perhaps from entirely different tables, also makes sense to me. As a developer, the notion of having a database which already contains structures that map easily into your class model (which I believe this would) must hold some appeal.

It’s all rather ironic since I have spent years with relational databases – and I have been happy to do so, since RDBMS has been so successful and reliable.

So where does this get us? Well, relational won the database war many many years ago and I don’t believe in fighting wars that don’t need to be fought. So is it a rather fruitless debate? Many people would say yes. On the other hand, though, occasionally you do get people questioning relational, and the debate tends to drift on to object oriented databases (yawn) which people have been banging on about for decades – and even more fruitlessly since they have never been used in any large scale commercially. At least Prime INFORMATION, Pick, and all the other variations did make an impact and were widely used – and in a characteristic irony of the computing industry, perhaps they were just around at the wrong time: a time before development tools were good enough to properly harness them.

If people do fancy a change, I’d like to think people looked around at genuine alternatives based on problems that have already been addressed and products that already exist and build on them, but as is so often the case, I doubt it.