Please note that this story is over 18 months old. It may be outdated.

Yet again, while running around the great inter-web, I found an interesting article which compares different database paradigms. The comparisons provided are between relational, document, key/value, and column-oriented databases. This lead me to thinking back to a comment that someone recently said to me that they use UniVerse as a document store database.

At the time, I thought – what the … But then again, there just might be something in this:

As I have stated before, I consider that the U2/PICK database model to be very ER (Entity-Relationship) Model based; hence the name I use: DDERDBMS – Dictionary-Driven Entity-Relationship DataBase Management System.

This makes sense, as the data is structured as ER relationships, and in most cases does not need to be normalized (think back to your text book ERD chapter). The actual fields, attributes, and values are then defined at the dictionary level.; where the dictionary definitions actually ‘point’ to fixed positions within the database e.g. <1,2>.

But, what about the UniBasic coding environment? Fields are not actually referenced by the data dictionary definitions. They are referenced as either a static multidimensional array or as a dynamic array,  essentially as a document structure. Of cause, like many other people, I have written or used some sort of utility to create a series of EQUATE statements for each data file, which can be INCLUDE’d within the appropriate UniBasic source code so some sort of relevance between the field and value numbers and names exist. Even SB+ has such a utility. But, even then, the ASSOCIATIVE relationship between fields and values are not known within UniBasic. It’s all manually managed outside of the programming environment (think paper, the brain,and a good memory).

But, at the end of the day, all references of fields and values are via positional numbers, not by actual field names. There are significant advantages and disadvantages, as expected; lack of self-documenting code is the first one that comes to mind as a major disadvantage.

So, what is the big deal? Well, over the last couple of months, longer maybe, there has been spurts of chatter within the couple of U2 forums about the future of U2 (market is growing?) and job opportunities etc. Ignoring all the politics which exists between the Haves (VAR’s) and the Have-Nots (employees and contractors) the general consensus is that the market has changed. This is  due to the way that U2 is used. It is no longer used as a complete front-end to back-end development environment. There are now multiple front-ends to consider (desktop, phone, web, tablet!) with better tools to create and maintain them. U2 is being relegated to the back-end.

This is a trend that no-one should be surprised with, as in the distant past, PICK -type databases were the OS, database, programming environment, and the client interface. Over time each of these functions have been replaced with more generic, and better alternatives e.g. the OS is now either MS-Windows or Linux (Unix).

So, if you are using a client/server structure for access to the U2 database, then there is probability an API. Therefore, using U2 Access for report generation must be on the decline, and the use of the dictionary definitions for a data file are for documentation reasons only? Well, using the field definitions does come in handy for implementing indexing and the odd SELECT statement, I suppose.

Which comes back to the UniBasic programming paradigm environment. Reading a record returns a collection of  multiple collections of multiple values, which all have positional relevance. Something like a document-oriented database.