3 ms·
I think this is somewhat misleading. > People forget, no matter how much optimization you do, joins are slow - and it is for exactly this reason that Mongo is
by RaphiePS 13y ago
I think this is somewhat misleading.
> People forget, no matter how much optimization you do, joins are slow - and it is for exactly this reason that Mongo is fast, with usually 5ms response times.
Yes, joins can be slow, but that's not the reason that Mongo is fast. The presence of a join feature doesn't slow down a database, just its use. Seems like just more anti-SQL FUD.
> At least with Mongo you are in explicit control of the speed of your database.
I don't see how Mongo gives you any more control in this respect -- joins are totally optional in a SQL DB.
- marknadal 13y agoRight, but what is the point of using a relational DB if you aren't going to do joins? (And equally knocking myself: There isn't much point doing relations in MongoDB... if that is what you need, use SQL. Lol.)
- splawn 13y agoThis highlights something i don't understand about non-relational DBs. Is there an actual use case for a database with multiple tables of unrelated data or is it a complexity trade-off thing?
- marknadal 13y agoYes, most of my actual data is just streams of inputs, that I only once-in-a-while-occasionally want to do some sort of MapReduce on. Most of the time, I just want my individual streams, and then pipe them around - and that is it. (Great for realtime systems, aka Node apps).
- aeorgnoieang 13y agoThat's interesting, actually. So logs would be good candidates for these kinds of DBSs?