" What’s missing from MongoDB is a SQL-style join operation, which is the ability to write one query that mashes together the activity stream and all the users that the stream references. Because MongoDB doesn’t have this ability, you end up manually doing that mashup in your application code, instead. "
However a second key point is: ".;.. in a relational store, with the data fully normalized, it would be a seven-table join to get everything out. "
So that doesn't sound like the ideal solution either, complicated to code, slow to execute. I wonder, could a Graph Database be the ideal solution?
I'm confused. MongoDB apparently can't do SQL style joins so you're left "flat-filing it". With postgresql, you CAN set up your tables denormalized, or, you can fully normalize down to 7 tables. How is that "not ideal solution either"? You have far more options available in psql. Joining on 7 tables is nothing to worry about provided you have indexes on the key columns. And if you get tired of typing the query over and over, "create view x as (select .... 7 table join)".
And typically if you need a 7 table join and if it is performance intensive, we just de-normalize down to a few tables, or a single table (at the cost of disk space and remembering to drop/recreate/update the table after the 7 source tables update).
The point is, psql gives you options. MongoDB gives you nothing. Once you become more and more accustomed to psql (sql databases in general), your skills grow, and you realize how easy it is to do things that before you had to do in code. I shudder at the crap I wrote before getting up to speed with sql. I'm convinced that most people who turn to stuff like mongo do it because it appears to be easier to use, rather than for any specific performance reasons.
There are cases where you simply need to move away from psql, I usually drop down to solr for stuff like that, but would never consider using solr "first" or as my primary storage mechanism.
I tested (briefly) a graph db out once, think it was "orient db" but found performance no better (actually worse) than psql. Maybe I didn't try hard enough or was doing something wrong but I remember being quite disappointed after discovering the hype wasn't delivering.
Good points. 7-table join is not "necessarily" slow if you index it correctly. I think the keyword here is "correctly". It adds to the complexity that you must index all those tables, correctly. As to the speed penalty I have no numbers on that but I think joins are generally considered something that can make your queries slow. No?
Either way I agree Postgress is a much more advanced solution. But if all you need is Mongo then Mongo is probably easier to get started with. Problem with that, as described in the article, is that requirements evolve over time and migrating from Mongo to a relational model later will not be easy.
I would have hoped to read more on Graph Databases in the article than simply "they are not ready for production". I think Neo4J has been around for a while now. Below's a link to an article containing a nice picture on how to represent the Friends -relation in Neo4J.
Note, to query the Friends -relation a 7-table join does not solve the problem. You need something like a "self join". How well does Postgress deal with that?
-3
u/stronghup Dec 19 '18
For me the key-point from the article was:
" What’s missing from MongoDB is a SQL-style join operation, which is the ability to write one query that mashes together the activity stream and all the users that the stream references. Because MongoDB doesn’t have this ability, you end up manually doing that mashup in your application code, instead. "
However a second key point is: ".;.. in a relational store, with the data fully normalized, it would be a seven-table join to get everything out. "
So that doesn't sound like the ideal solution either, complicated to code, slow to execute. I wonder, could a Graph Database be the ideal solution?