3 ms·

> 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 a

by porker 9y 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.

orf 9y 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.
- porker 9y ago
  > 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.
paulmd 9y ago
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.
- porker 9y ago
  Sure: http://mikehillyer.com/articles/managing-hierarchical-data-in-mysql/ 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.

by porker 9y ago

orf 9y 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.

porker 9y ago
> 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.

paulmd 9y ago

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.

porker 9y ago
Sure: http://mikehillyer.com/articles/managing-hierarchical-data-in-mysql/ 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.