4 ms·

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

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 this is doubly true for databases; at least with obfuscated code, you can recover the underlying meaning with work and exploration. Losing or corrupting data is the worst thing a database can do. Given "this will be correct and hopefully we can scale it" vs "this will be fast and hopefully we can keep it correct", I'd choose the former for any "source of truth" data every time. There are tricks for speeding up queries - indexes, cacheing (including materialized views), sharding, read replicas, etc. There are no tricks for recovering data you lost.

andy_ppp 9y ago
> 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 dollars.
- crdoconnor 9y ago
  >Clearly people building simple crud websites with slick JS features didn’t agree 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.
- gameswithgo 9y ago
  >Clearly people building simple crud websites with slick JS features didn’t agree otherwise Mongo would be gone Popularity is not always a good measure of what ideas are good ones.

andy_ppp 9y ago

> 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 dollars.

crdoconnor 9y ago
>Clearly people building simple crud websites with slick JS features didn’t agree 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.
gameswithgo 9y ago
>Clearly people building simple crud websites with slick JS features didn’t agree otherwise Mongo would be gone Popularity is not always a good measure of what ideas are good ones.