Hacker News new | ask | show | jobs
by porker 3162 days ago
> NoSQL really fits best around the margins, like as an auxiliary system for analytics.

I'd say it also fits well in two niches: document datastores (so long as there's some JOIN support, via referencing nested documents vs direct nesting) and graph stores.

I remember 10+ years ago working on storing nested sets in the RDBMS and it wasn't pretty. And the RDBMS schema for Magento 1, with key-value tables all over the place which NoSQL would have removed the need for.

2 comments

Can you define what "nested sets" means more specifically?

Postgres supports hierarchical/nested structures using the "ltree" column type. There is nothing stopping you from defining a primary key of (eg) "set1.set10.set100". There is also support for recursive views/etc to operate on these kinds of sets.

Again, if you have some kind of "sparse" column, it can make sense to put that into a JSONB column. This is effectively the same thing as attaching an unstructured document to a record for this use-case.

Sure: http://mikehillyer.com/articles/managing-hierarchical-data-i...

Joe Celko popularised them. I've been unable to find when they were first introduced; but a search of my source code archive points to having written one ~14 years ago.

> so long as there's some JOIN support, via referencing nested documents vs direct nesting)

Which has its own problems. PG does this just fine, with a full battle-tested relational system to back it (and you) up.

> with key-value tables all over the place which NoSQL would have removed the need for.

Product X having a stupid schema is not a good basis for an argument for or against a particular product.

> Product X having a stupid schema is not a good basis for an argument for or against a particular product.

What other way could Magento have implemented user-defined columns at the time, using a RDBMS? In 2009 when MongoDB was released, JSON columnstores were something to dream of and the alternative was storing serialised data in a BLOB field. That "stupid schema" did not have an alternative I can think of, except NoSQL.