9 ms·

That doesn't make sense to me. A single query is faster than a join. Designing things for your application's purpose seems fairly tangible to me. It's applicati

That doesn't make sense to me. A single query is faster than a join. Designing things for your application's purpose seems fairly tangible to me. It's application dependent. I use both for different B2B businesses I work with. One works very well with Mongo and would simply be slower with SQL. The Mongo app has one point of access for writes, while everything else is reads. It's near impossible to become inconsistent. The other application would be an absolute shit-show if it used Mongo. I'd never sleep at night with a fear of it failing. Nothing is black and white, and choosing the wrong technology isn't a failure of the technology.

yummyfajitas 11y ago
Obviously a single query is faster than a join, but it's very hard to guarantee that you'll always be making that single query. Data inconsistency is not about concurrency. See this example on Wikipedia illustrating why 3NF is necessary: https://en.wikipedia.org/wiki/Third_normal_form#.22Nothing_but_the_key.22 https://en.wikipedia.org/wiki/Third_normal_form#.22Nothing_b... In that example, "Al Fredrickson" can potentially have 2 birthdays even in an entirely single threaded app. I'm really curious to hear a use case where Mongo was actually significantly faster than Postgres. Could you give a toy example that illustrates the flavor of the problem?
- lloyd-christmas 11y ago
  One of our applications I jokingly call "mad libs". It's effectively a document generator. A single point of entry for constructing the document skeleton (admin). The data structure for it is recursive, while user data is meta driven. Any necessary data on any given page is a single query. The only directly related multiple-query is the skeleton construction on the admin side. That part is fairly complicated (and swarmed with tests). There are potential inconsistency issues which could only come about if the admin was putting in a fair amount of effort into destroying their own app (spam POST/PUT wouldn't even cause it). Since the possibility exists even in the near-impossible, there are eventual consistency tasks running. But again, it would be pretty impressive to actually get it inconsistent. Given that the user side is meta driven anyway, there aren't any lasting effects on their side. Had we gone with SQL, the query for the (recursive) skeleton would have been 3 tables, one of which would be recursive. My use case is where reading drastically trumps writing. This tends not to happen in the unicorn industry, so I fully agree that it's silly in many _publicly discussed_ applications. But many B2B applications can fit the use case.
  - Jweb_Guru 11y ago
    You didn't respond to the question about speed. Probably because Mongo has been considerably slower than Postgres in virtually every apples-to-apples comparison I've seen.

yummyfajitas 11y ago

Obviously a single query is faster than a join, but it's very hard to guarantee that you'll always be making that single query. Data inconsistency is not about concurrency. See this example on Wikipedia illustrating why 3NF is necessary: https://en.wikipedia.org/wiki/Third_normal_form#.22Nothing_but_the_key.22 https://en.wikipedia.org/wiki/Third_normal_form#.22Nothing_b... In that example, "Al Fredrickson" can potentially have 2 birthdays even in an entirely single threaded app. I'm really curious to hear a use case where Mongo was actually significantly faster than Postgres. Could you give a toy example that illustrates the flavor of the problem?

lloyd-christmas 11y ago
One of our applications I jokingly call "mad libs". It's effectively a document generator. A single point of entry for constructing the document skeleton (admin). The data structure for it is recursive, while user data is meta driven. Any necessary data on any given page is a single query. The only directly related multiple-query is the skeleton construction on the admin side. That part is fairly complicated (and swarmed with tests). There are potential inconsistency issues which could only come about if the admin was putting in a fair amount of effort into destroying their own app (spam POST/PUT wouldn't even cause it). Since the possibility exists even in the near-impossible, there are eventual consistency tasks running. But again, it would be pretty impressive to actually get it inconsistent. Given that the user side is meta driven anyway, there aren't any lasting effects on their side. Had we gone with SQL, the query for the (recursive) skeleton would have been 3 tables, one of which would be recursive. My use case is where reading drastically trumps writing. This tends not to happen in the unicorn industry, so I fully agree that it's silly in many _publicly discussed_ applications. But many B2B applications can fit the use case.
- Jweb_Guru 11y ago
  You didn't respond to the question about speed. Probably because Mongo has been considerably slower than Postgres in virtually every apples-to-apples comparison I've seen.