The Pick / MultiValue DBMS for Relational DBMS users

In the jBase forum someone was recently looking for a jBase tutorial for Oracle/RDBMS users, or for someone new to databases in general. Many years ago I did a presentation called Pick for Relational Experts. It included the points presented here, which apply to all Pick/MultiValue DBMS platforms. I welcome others to compare and contrast jBase/MV with Relational, and comments from those more familiar with the relational environments as well.

This is just a quick, unsorted list of comparisons and comments. A web page was also created several years ago which supplements the information found here. If there is any interest I might organize and formalize it a bit more later.

We optionally use Values in records rather than creating nested/joined tables. This isn’t mandatory, it’s versatility that we enjoy, and it’s the reason why we call these systems MultiValued or MultiDimensional. We might have one attribute to store multiple telephone numbers or another to store address1 and address2, rather than using separate attributes or separate files.

We have one more tier down within data called SubValues. We might have a single attribute for sales quantities, with values for months with each value broken into subvalues for days. We aren’t compelled to store data like this, it’s an option which isn’t available in relational environments.

We use a dictionary to define Views and we put all logic into BASIC Stored Procedures. We use queries for inquiry only, we generally do not do CRUD operations with queries, though this is possible.

Updates to data structures are not dependent on the dictionary/schema and these are often out of sync. Relational people choke on this but again, we see this as versatility.

jBase/MV data is dynamically typed (popular these days but a horrific concept to many some years ago), with everying being a string unless it’s referenced as a number. The DBMS doesn’t type the data, this is done in the application – it’s more like JavaScript or VBScript in this regard, rather than Java/C++.

Referential Integrity is not maintained at the database/schema level but in the BASIC business rules. Again, RDBMS people will choke on this but we’re simply moving the responsibility for RI from a DBA and the DBMS/schema to a Programmer and BASIC. The disadvantage is that two programs can enforce different rules, or ignore RI requirements – but we like enough rope to hang ourselves many times over. We can use Triggers to make this work more like a relational environment – again, it’s all about versatility.

In the Pick/MultiValue environment people use the database for everything including programs and report definitions. RDBMS people aren’t so used to putting everything inside the box. This isn’t a requirement, it’s just another versatility that we enjoy.

If you’re new to databases, the MV DBMS environment is ideal in that you are allowed to store and retrieve data without getting side-tracked by things like schema, RI, relations, inner/outter joins, and data types. You open a file, write an item with a key, then retrieve it and manipulate attributes. It’s dirt-simple – and it’s a real shame that most new developers these days are side-tracked from their Web2.0/RIA development to learn about conventional database usage when it’s not necessary.