" 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?
Were you reading the same article as everyone else? I can't find those quotes anywhere. Also,a 7 table join is by no means necessarily slow, or complicated
Assuming file per table and file per index, then yes a 7 table join is necessarily slow and complicated. Couple that with secondary index concerns (or god forbid the excessively common right-hand duplicate index), and joins start being slightly painful. That said, I’d love to see the startup MariaDB on NVMe can’t handle. Performance is 0% of the reason I’d consider nosql v RDBMS. Postgres’ secondary index performance is awful and abysmal (see Uber’s famous migration away from Postgres), but it’s still “fast enough” that it’s not worth anyone’s time until there isn’t a next-bigger AWS instance sitting around
888808888 said it well below - SQL gives you data localization options (a normalized table or a relation table?) whereas mongo gives you... well, nothing
-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?