6 ms·

Right, but most people using it use model or data repository patterns to ensure correctness. It does offer nearly infinite flexibility provided you use it corre

Right, but most people using it use model or data repository patterns to ensure correctness. It does offer nearly infinite flexibility provided you use it correctly. You can add fields without any sort of DB work, you just start adding fields to rows as needed and let it catch up organically. There are use cases where mongo makes a lot of sense. It's very popular in the node.js / RAD world for sure. I certainly have never been a huge fan by any means. Only relatively recently did they solve distributed writes.

toomuchtodo 8y ago
Unfortunately, I’d argue PostgreSQL gets you all the same benefits with JSON storage (fairly equivalent to Mongo docs), while also giving you all the goodness of a relational, transactional, schema enforcing RDBMS. PGSQL became Mongo faster than Mongo could become PGSQL.
- WrtCdEvrydy 8y ago
  This is the same thing that happened in Java. Other languages started prototyping features... that eventually just end up being implemented in Java.
  - int_19h 8y ago
    Java did it way too slow, and that is a significant contributor to it being relegated to "legacy" in many areas. If it waited for the other languages to prototype stuff, it might have not been the case. The problem is that it waited for them to prototype it, refine it, release it, popularize it, and for their community to adopt it, before even starting to work on it in Java - which means that by the time they had it, most people who needed it were already elsewhere (not necessarily off JVM, just another language). Lambdas were a very good example - if you look at the closest competitor, C#, it got the first take on them back in 2005. Then a major refinement in 2008, adding type inference. By 2010, lambdas were idiomatic in C#. Java, in contrast, released the first version in 2014. And even then, they're still less powerful.
    - kjeetgill 8y ago
      Huh. I didn't know they worked any differently in C#. In what ways are they less powerful in Java?
      - int_19h 8y ago
        For example, in Java, lambdas cannot capture mutable variables from the outer scope - it must be final, or effectively final. C# always let you do that, from the very first implementation of lambdas.
        eropple 8y ago
        C# lets you do that because C# doesn't have a way to declare a local readonly/final variable at all. I significantly prefer features that encourage the use of `final` variables everywhere that it is possible in Java. I write C#, Java, and Kotlin in roughly equal measure. Each has its pluses. But the claim that Java's lambdas are worse because it doesn't let you--and this was a conscious design choice!--do something so potentially catastrophic and difficult to debug is an odd one.
        manigandham 8y ago
        I rather be able to do something than be prevented because someone somewhere thinks that it's "potentially catastrophic". That seems especially hyperbolic in this case.
        kjeetgill 8y ago
        To each their own, but I can second that most Java programmers find that ability horrifying and if it came to a vote would probably get it ejected.
        int_19h 8y ago
        Do Java programmers find mutable variables in general horrifying? That was not my impression - certainly, the language doesn't make it easy to make everything immutable. If so, why the special distinction for lambdas? The official rationale was that they expected lambdas to be mostly used for parallel sequence processing, and wanted to avoid race conditions. Of course, in practice, lambdas are very useful in many other places, where there's no concurrency issue at all - async continuation callbacks, for example, or pseudo-custom language constructs implemented as functions with a lambda for a body.
  - imtringued 8y ago
    A lot of useful features don't end up being implemented in Java and even if they do, libraries and frameworks have to update to take advantage of them. With a new language libraries are built from the ground up based on the new features. For example adding async to the language isn't necessarily going to change your programs to be async because every widely used library has already adopted threads and doesn't support async yet and often never will.
- d4l3k 8y ago
  Pretty much all of the things you'd want in a relational database are now present in Mongodb too. The real benefit of MongoDB at this point is the ability to easily scale beyond a single machine with shards and high availability using replica sets. Postgres will get you pretty far, but beyond a certain point the scaling story breaks down and you have to hack some sort of user space sharding solution. At that point all the schema update and backups become a nightmare. Schemas: https://docs.mongodb.com/manual/core/schema-validation/ https://docs.mongodb.com/manual/core/schema-validation/ Transactions: https://docs.mongodb.com/manual/core/transactions/ https://docs.mongodb.com/manual/core/transactions/ SQL: https://docs.mongodb.com/bi-connector/master/ https://docs.mongodb.com/bi-connector/master/
  - ams6110 8y ago
    Most databases will never need this kind of scaling.
    - atm0sphere 8y ago
      https://m.youtube.com/watch?v=b2F-DItXtZs https://m.youtube.com/watch?v=b2F-DItXtZs
  - pritambaral 8y ago
    > Pretty much all of the things you'd want in a relational database are now present in Mongodb too. On the "relational" front, it has denormalized-only schema validation and limits transactions to replica sets (so no transactions with sharding), while also recommending single-document transactions over multi-document transaction via denormalization. (FWIW, transactions aren't available in any open source release). On the "database" front, it has a history of misleading users and remorselessly dropping data. > Postgres will get you pretty far Postgres is an actual relational database, open source, battle-proven with a good design and a great team behind it. It never claimed to be good at, let alone capable of, doing things it could not actually do (well, or at all). > but beyond a certain point the scaling story breaks down and you have to hack some sort of user space sharding solution. Scaling IS a hard thing, and presents itself quite differently to different use-cases. Nevertheless, horizontally scaling Postgres — for when one truly hits the petabyte-scale — is a problem that has been solved correctly many times before (out of core). For a similar-to-MongoDB method, check out Citus, with the assurance that it only adds to an actual database; as opposed to the MongoDB way of doing things: make up and promise magic scaling solutions that "Just Work", then try to build a database on top of it.

toomuchtodo 8y ago

Unfortunately, I’d argue PostgreSQL gets you all the same benefits with JSON storage (fairly equivalent to Mongo docs), while also giving you all the goodness of a relational, transactional, schema enforcing RDBMS. PGSQL became Mongo faster than Mongo could become PGSQL.

WrtCdEvrydy 8y ago
This is the same thing that happened in Java. Other languages started prototyping features... that eventually just end up being implemented in Java.
- int_19h 8y ago
  Java did it way too slow, and that is a significant contributor to it being relegated to "legacy" in many areas. If it waited for the other languages to prototype stuff, it might have not been the case. The problem is that it waited for them to prototype it, refine it, release it, popularize it, and for their community to adopt it, before even starting to work on it in Java - which means that by the time they had it, most people who needed it were already elsewhere (not necessarily off JVM, just another language). Lambdas were a very good example - if you look at the closest competitor, C#, it got the first take on them back in 2005. Then a major refinement in 2008, adding type inference. By 2010, lambdas were idiomatic in C#. Java, in contrast, released the first version in 2014. And even then, they're still less powerful.
  - kjeetgill 8y ago
    Huh. I didn't know they worked any differently in C#. In what ways are they less powerful in Java?
    - int_19h 8y ago
      For example, in Java, lambdas cannot capture mutable variables from the outer scope - it must be final, or effectively final. C# always let you do that, from the very first implementation of lambdas.
      - eropple 8y ago
        C# lets you do that because C# doesn't have a way to declare a local readonly/final variable at all. I significantly prefer features that encourage the use of `final` variables everywhere that it is possible in Java. I write C#, Java, and Kotlin in roughly equal measure. Each has its pluses. But the claim that Java's lambdas are worse because it doesn't let you--and this was a conscious design choice!--do something so potentially catastrophic and difficult to debug is an odd one.
        manigandham 8y ago
        I rather be able to do something than be prevented because someone somewhere thinks that it's "potentially catastrophic". That seems especially hyperbolic in this case.
        kjeetgill 8y ago
        To each their own, but I can second that most Java programmers find that ability horrifying and if it came to a vote would probably get it ejected.
        int_19h 8y ago
        Do Java programmers find mutable variables in general horrifying? That was not my impression - certainly, the language doesn't make it easy to make everything immutable. If so, why the special distinction for lambdas? The official rationale was that they expected lambdas to be mostly used for parallel sequence processing, and wanted to avoid race conditions. Of course, in practice, lambdas are very useful in many other places, where there's no concurrency issue at all - async continuation callbacks, for example, or pseudo-custom language constructs implemented as functions with a lambda for a body.
- imtringued 8y ago
  A lot of useful features don't end up being implemented in Java and even if they do, libraries and frameworks have to update to take advantage of them. With a new language libraries are built from the ground up based on the new features. For example adding async to the language isn't necessarily going to change your programs to be async because every widely used library has already adopted threads and doesn't support async yet and often never will.
d4l3k 8y ago
Pretty much all of the things you'd want in a relational database are now present in Mongodb too. The real benefit of MongoDB at this point is the ability to easily scale beyond a single machine with shards and high availability using replica sets. Postgres will get you pretty far, but beyond a certain point the scaling story breaks down and you have to hack some sort of user space sharding solution. At that point all the schema update and backups become a nightmare. Schemas: https://docs.mongodb.com/manual/core/schema-validation/ https://docs.mongodb.com/manual/core/schema-validation/ Transactions: https://docs.mongodb.com/manual/core/transactions/ https://docs.mongodb.com/manual/core/transactions/ SQL: https://docs.mongodb.com/bi-connector/master/ https://docs.mongodb.com/bi-connector/master/
- ams6110 8y ago
  Most databases will never need this kind of scaling.
  - atm0sphere 8y ago
    https://m.youtube.com/watch?v=b2F-DItXtZs https://m.youtube.com/watch?v=b2F-DItXtZs
- pritambaral 8y ago
  > Pretty much all of the things you'd want in a relational database are now present in Mongodb too. On the "relational" front, it has denormalized-only schema validation and limits transactions to replica sets (so no transactions with sharding), while also recommending single-document transactions over multi-document transaction via denormalization. (FWIW, transactions aren't available in any open source release). On the "database" front, it has a history of misleading users and remorselessly dropping data. > Postgres will get you pretty far Postgres is an actual relational database, open source, battle-proven with a good design and a great team behind it. It never claimed to be good at, let alone capable of, doing things it could not actually do (well, or at all). > but beyond a certain point the scaling story breaks down and you have to hack some sort of user space sharding solution. Scaling IS a hard thing, and presents itself quite differently to different use-cases. Nevertheless, horizontally scaling Postgres — for when one truly hits the petabyte-scale — is a problem that has been solved correctly many times before (out of core). For a similar-to-MongoDB method, check out Citus, with the assurance that it only adds to an actual database; as opposed to the MongoDB way of doing things: make up and promise magic scaling solutions that "Just Work", then try to build a database on top of it.