Earlier quoted context omitted.
Both approaches have downsides. The TCP/IP stack was built and used while the OSI model was being designed, and it won all the mindshare. Perhaps it would have been better to have separate presentation and session layers, but we don't; the application layer handles that stuff. It works well enough. OTOH, this quote is wise: > It is easier to optimize correct code than to correct optimized code (Bill Harlan) I think t…
> I think this is doubly true for databases; at least with obfuscated code, you can recover the underlying meaning with work and exploration. True for databases, but not true for businesses . > Losing or corrupting data is the worst thing a database can do. Clearly people building simple crud websites with slick JS features didn’t agree otherwise Mongo would be gone and Rethink would be worth hundreds of millions of…
I doubt it's that they didn't agree, it's more likely that the thought simply never occurred to them.
Mongo's marketing is directed with laser like focus on the beginner developer seeking out tutorials to build a website, etc. Questions about data consistency simply never arise in that context.
Later on that developer who was gently guided towards using mongo by all of the slick marketing will likely try to defend their decision when somebody attacks it ("their data consistency problems aren't that bad" or "data consistency isn't that important"), but that's something else.