Ask HN: Are there still good use cases for multivalue databases?

2 pointsmrsalt6y ago6 comments

Have you worked with them? Do you think there is any reason for using them in 2019? (besides legacy software)

https://en.wikipedia.org/wiki/MultiValue https://en.wikipedia.org/wiki/Pick_operating_system

6 comments

I worked with them for years, mostly UniVerse and UniData. The short answer is no, I don't think there is a reason to base any new work using a Pick based MVDB. Don't get me wrong, I see some value in what they were trying to accomplish, but today there are NoSQL solutions which are far superior to how these old Pick style solutions were built. File corruption was a real pain and normal reality, searching, sorting and managing the data took a full time DBA/SysAdmin for even smaller implementations. Mixing the language and database as most of these systems did too was a mess to manage, version control was a pain usually, value typing was not good and error handling was always a challenge to do it even just ok at.

To be fair, I do see some elegance in how they work, but just the trade-offs today aren't the same, so IMO there isn't a good reason to use them when we have graph databases, the modern NoSQL solutions and SQL for that matter.

Essentially, a current document database does more than these solutions can and more reliably.

This is also why, I didn't see NoSQL solutions, like Mongo et al, as something so revolutionary when they came out, to me they are just a modern twist on things we have had for decades.

mrsaltOP6y ago

Thanks for commenting. My current job involves working (though in a minimal way) with a heavily modified install of Rocked U2 which has its own version control, kind of its own BASIC dialect and I can only agree with what you say. It also forces you to use a special in-house terminal and text editor for ALL programs in BASIC. No vi or anything.

They have discussed of doing away with it for years (decades?) and it has never happened.

The biggest argument against migrating is "performance" (that a RDBMS or even Mongo will be slower).

davismwfl6y ago

Yea, I had two public companies as clients for my consulting business, one had the largest UniVerse install I had ever seen running literally their supply chain, inventory and invoicing applications. They were running ~$5 billion/year off it, but I know talking to IBM at the time that was far from the largest install. Their original argument was similar about concerns of performance, reliability etc. A lot of that was coming from their UniVerse/Pick engineers that didn't have current skills sets talking about how Oracle and SQL was slow and horrible etc. They were just out of touch with current solutions and partially burned by an Oracle applications project gone horrible (don't they all), all of which is why we were brought in by the CTO's office.

We replaced their solution with Postgres, proper caching and clear separation of concerns/layers and they went from queries taking 3-4 second average (some being 30-40 second normally) to being done in 500ms-1s average. Another thing we fixed, some of their data had to be batch processed overnight everyday for like pricing adjustments on the UniVerse system, because concurrency was a major problem for them. After our changes they did real-time pricing adjustments along with a bunch of other similar things. We built them a proper OLTP data solution with a data warehouse with cubes for detailed analytics & reports.

I don't envy anyone having to still work in one of these systems, so many times simple things you could do in a modern system in short durations will turn into a nightmare and a huge drawn out project in Pick/U2. I definitely don't agree with the performance argument, I fought that one for years with different clients and vendors who felt U2 was so fast, and with a properly designed RDBMS I always could beat their performance, especially when concurrency was a key factor. Locking on U2 systems is a complete cluster most of the time for high concurrency systems.

1 more reply

j / k navigate · click thread line to collapse

6 comments

davismwfl6y ago

Essentially, a current document database does more than these solutions can and more reliably.

This is also why, I didn't see NoSQL solutions, like Mongo et al, as something so revolutionary when they came out, to me they are just a modern twist on things we have had for decades.

mrsaltOP6y ago

They have discussed of doing away with it for years (decades?) and it has never happened.

The biggest argument against migrating is "performance" (that a RDBMS or even Mongo will be slower).

davismwfl6y ago

1 more reply

j / k navigate · click thread line to collapse