DB-Engines site - MV represented

124 views
Skip to first unread message

Kevin Powick

unread,
Jan 11, 2016, 8:40:39 AM1/11/16
to Pick and MultiValue Databases
An interesting database ranking site that I don't recall seeing before.  Multivalve databases are represented, even some I didn't know.

http://db-engines.com/en/ranking

--
Kevin Powick

Dawn Wolthuis

unread,
Jan 11, 2016, 8:52:11 AM1/11/16
to mvd...@googlegroups.com
This is definitely interesting because Rocket likely had a hand in classifying Model 204 as a "Multivalue" database. Notice it is not "MultiValue" for which International Spectrum holds a trademark, as I recall. Rocket knows the difference between MultiValue, aka PICK, and Multivalue, as in a database for which a single attribute can have multiple values.

My hunch is that Rocket is trying to blend all of their databases into a single entity rather than having a MultiValue division within the company. That could have a similar effect to U2 being within IBM where DB2 was the big dog or MultiValue being one way to implement Cache' where the company would never recommend it to anyone not already using PICK. In other words, if we start hearing more about Model 204, I will get that uncomfortable feeling. Is there anyone at Rocket who can clue us in to whether Model 204 has just been poured into the same pot as U2 and D3?

--dawn

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com
To unsubscribe, email to: mvdbms+un...@googlegroups.com
For more options, visit http://groups.google.com/group/mvdbms



--
Dawn M. Wolthuis

Take and give some delight today

Dan McGrath

unread,
Jan 11, 2016, 11:15:08 AM1/11/16
to mvd...@googlegroups.com

I was the source for originally getting U2 DBs listed in DB-Engines when I was at Rocket, then connected the D3 folks to do the same.

I'm pretty confident there isn't much going on between M204 and U2 in the way described by Dawn. M204 is a mainframe solution and there is very little overlap between their customer bases/partners. Maybe some technical knowledge sharing.

Bruce Holt

unread,
Jan 11, 2016, 1:00:10 PM1/11/16
to Pick and MultiValue Databases
MultiValue Platforms and Mainframe Platforms are grouped together under "Application Platforms" for management, that's all. No attempts to merge all our databases into a "Rocket UbiQuitous" are in progress, as far as I know!

As for why DB-Engines has lumped M204 under MultiValue databases I couldn't say. I would only suspect it's because of the Rocket name and an assumption all Rocket databases would be MV.

YMMV (to purloin a Tony-ism)

Dawn Wolthuis

unread,
Jan 11, 2016, 2:06:36 PM1/11/16
to mvd...@googlegroups.com
Ah, that could be that they decided since the other Rocket products were Multivalue then Model 204 was too. They also have ADABAS under that category. It has been years since I looked at ADABAS, but my impression was that it was closer to a set of indexed-sequential files than to PICK. 

VSAM has files, records, and values, and could be listed as Multivalue, but it is not MultiValue.

If you got U2 listed, Dan, what do you think it would take to get the non-MV DBMS's reclassified?

--dawn


Dawn Wolthuis

unread,
Jan 11, 2016, 4:16:42 PM1/11/16
to mvd...@googlegroups.com
Bruce -- what is the name of the U2/D3 organization/department/group within Rocket? The web site is more mysterious to me right now than it has been. Who heads up MultiValue within Rocket?  Thanks.  --dawn

On Mon, Jan 11, 2016 at 12:00 PM, Bruce Holt <mvd...@gmail.com> wrote:

Bruce Holt

unread,
Jan 11, 2016, 5:06:47 PM1/11/16
to Pick and MultiValue Databases, dw...@tincat-group.com
Rocket has adopted a "One Rocket" initiative. Internal organization naming is not reflected in the web site and is totally generic in form.

John Bramley heads up the group containing the MV databases.

Dan McGrath

unread,
Jan 11, 2016, 7:25:15 PM1/11/16
to mvd...@googlegroups.com
You'd just contact them with content corrections and additional information. If they agree they'll update it. I took a look at ADABAS now and while technical implementation might be vastly different, it seems that at a conceptual level it looks very similar.

Files -> Records -> Fields, fields can be repeating groups (multiple of the same property) or multi-valued (multiple different properties).

It might not be capital V MultiValue (aka, Pick-like GIRLS/ENGLISH), but I think it fits into the same model and I think that's what they are going for.

Dawn Wolthuis

unread,
Jan 11, 2016, 7:45:17 PM1/11/16
to mvd...@googlegroups.com
Thanks Dan. All indexed-sequential files from the 70's, such as MIDAS on Pr1me and VSAM on big iron (I worked with both) had files, records, and fields with fields permitting both multivalues and "repeating groups" (associated multivalues). One huge difference was that the indexed sequential file systems were largely based on "cards" with fixed-length fields and without delimiters.

In other words, if you put everything with files, records, fields and multiple values into the category of Multivalue, then that category would include everything prior to relational databases. It would be a meaningless designation, I think. U2 is closer to MongoDB for data modeling than it is to VSAM.

--dawn

Dan McGrath

unread,
Jan 11, 2016, 8:02:44 PM1/11/16
to mvd...@googlegroups.com
Interesting thoughts! Maybe that is a correct way to categorize them? I honestly couldn't say since I have really researched them to determine how the data model and engines differ.

For U2 being closer to MongoDB, I respectfully disagree. :)
  • MongoDB stories field names and values side-by-side in every record, whereas U2 stores names and values completely separate.
  • In MongoDB, field names and values are tightly coupled in the data and query language, whereas in U2 they are not coupled in the data at all and interchangeably coupled in the query language.
  • U2 has relatively strict nesting of data restrictions based on available delimiters (3-9[?] levels depending on your engine) and the engines ability to process them, whereas MongoDB has no such limit.
  • MongoDB is inherently a distributed DBMS with multi-master support (database->multiple DBMS instances). U2 is not, although be hacked to give something related (DBMS instance->multiple databases).

Pros and cons are present in both approaches, but definitely different approaches.

Dawn Wolthuis

unread,
Jan 11, 2016, 9:28:16 PM1/11/16
to mvd...@googlegroups.com
Good points, Dan. Some of the difference in perspective is between application data modeling compared to storage engine design. I'm not diving down the the implementation of the DBMS, so I'm sure I'm missing that angle.

One notable difference between MV and MongoDB is the levels of nesting, as you mentioned. I would contend that it is rarely a good logical data model for line-of-business software to nest deeper than sub-values. With the MV application I have worked with the most, sub-values were even forbidden in the development standards. This did not hamper the design or implementation. This make sense because MV aligns with language. Sentences that nest beyond nesting a list or association are typically too complex.

On the other hand, the ability to be able to implement an arbitrary JSON document (or XML) within the database structure (rather than simply as a text document that is then parsed) is a nice feature of MongoDB and other databases, such as Cache' globals.

So, yes, I'll grant that one. 

The tight coupling of metadata and data is less clear to me, but I give the nod to MV from my perspective. I don't know how Mongo stores the data and metadata, but having descriptive rather than prescriptive metadata is a plus in MV. It allows the user vocabulary to be extensible (with synonyms and user-defined functions, for example), setting up for more natural queries. It is also very easy to refactor the data and metadata. On balances, it has a significant downside that there are not as many types of constraints within the DBMS, however. You get more rope to hang yourself with MV than with MongoDB.

When it comes to the distributed nature of MongoDB, it sounds like sharding is beyond painful, but yes, it ought to be more scalable as advertised.

BTW, I have talked with the MongoDB sales folks, and they would not really claim that a site can successfully deploy a production application with their open source DBMS. Some of the backup utilities are not included in the open source version, for example.

--dawn

Reply all
Reply to author
Forward
0 new messages