4 ms·

> SQL Generation after generation of programmers takes one look at SQL and decides it would be more convenient to believe that relational databases don't solve

by dkarl 6y ago

> SQL Generation after generation of programmers takes one look at SQL and decides it would be more convenient to believe that relational databases don't solve any of their problems. If there's one thing I would recommend to engineers at any point in their career it would be to, if they haven't already, learn enough SQL and enough about relational databases to feel comfortable using them for what they're good for. You start to see a whole class of problems as solved. And there are still plenty of cool problems to work on that relational databases don't solve well.

cheez 6y ago
And if you aren't convinced, SQLite (and postgres) implemented MongoDB as a feature ;-)
- StavrosK 6y ago
  Which should be used very sparingly, unlike the actual MongoDB, which shouldn't be used at all.
  - cheez 6y ago
    haha. I use it for application plugin configuration values which allows plugins to do whatever they want but also provides some structure just in case sweeping changes need to be made. Basically where schemas aren't important or will be defined by someone else.
  - jointpdf 6y ago
    I’ve heard (way) more than one story about MongoDB mysteriously annihilating all the data. Launched into oblivion. The worst imaginable outcome for a database.
    - StavrosK 6y ago
      Oh yeah, I have two of those myself.
    - cheez 6y ago
      jeebus
    - TimTheTinker 6y ago
      It's worth mentioning that MongoDB used to have a terrible storage engine--and it would do all sorts of stuff like this under stress. But it was replaced with a much better engine (WiredTiger) with write-ahead journaling and checkpoints around the year 2016.
      - jlokier 6y ago
        In 2020, MongoDB continues to fail consistency tests. "Jepsen Disputes MongoDB’s Data Consistency Claims" https://www.infoq.com/news/2020/05/Jepsen-MongoDB-4-2-6/ https://www.infoq.com/news/2020/05/Jepsen-MongoDB-4-2-6/ "MongoDB 4.2.6" http://jepsen.io/analyses/mongodb-4.2.6 http://jepsen.io/analyses/mongodb-4.2.6
    - joedrumgoole 6y ago
      I've worked at MongoDB for seven years right next to our EMEA/APAC support teams. We've never come across and instance where MongoDB was "mysteriously annihilating all the data". We would take any incidence of that whether it was a paying customer or not very seriously. If you know someone this has happened to I would encourage you to get them contact us. Joe Drumgoole Director of Developer Relations, MongoDB
eikenberry 6y ago
> Generation after generation of programmers takes one look at SQL and decides it would be more convenient to believe that relational databases don't solve any of their problems. I think this also goes toward the point of why they all do this... that SQL isn't what most developers like or want. SQL is an complex data manipulation DSL that most of the time is complete overkill for what you need and using something simpler and more specifically oriented toward your requirements makes more sense. Personally I was pretty good with SQL 15 years back but have moved on and don't regret not having needed it as the various non-RDBMS systems have more that met all my needs.
- the_af 6y ago
  > that SQL isn't what most developers like or want "Most" developers? That's debatable. But I can tell you a lot of people I talked to who chose MongoDB didn't have a single good reason for choosing it. For some, it's the only DB they are familiar with ("I used it before"). Others had vague, badly-argued reasons such as "the schema might change" or "it's faster to just use MongoDB". Seasoned DBAs almost always shook their heads in disapproval (and ended up being proven right).
  - gravypod 6y ago
    > For some, it's the only DB they are familiar with ("I used it before") I'm sure some of the reasons you use your RDBMS of choice over another implementation or a NoSQL system distill to, at some point, "I used it before". Familiarity is a feature. This is especially true if your org invests in tooling that improves the usability of a DB. > badly-argued reasons such as "the schema might change" or "it's faster to just use MongoDB" Why are these badly-argued reasons? I currently work on a codebase that is making heavy use of MongoDB. We are using it as a way to store protobufs which will change very frequently in structure (adding new fields, removing old fields, etc). Our software is built so that it supports older versions of protos which is already needed for backwards-compatibility in APIs. Because we're using Mongo I've written a simple connector that maps our protos into Mongo that allows documents in a collection to map well into proto access semantics (default to emptiness). If a frontend developer wants to save some new field into a database they: 1. Add the field into the proto 2. Validation field in service (optional) We don't have any ops work needed. We don't have any roll forward or roll back planning needed. Since we're a really small team this flexibility afforded to us is a huge velocity boon. Since we use gRPC we push people towards not making backwards incomparable API which makes our mongo-mapper very basic. We are also planning on making use of things like `watch()` which is possible to do in some hacky ways in postgres but it's very easy to do with this architecture. I've never had as smooth an experience with PG/MySQL/SQLite, even with ORMs. > Seasoned DBAs almost always shook their heads in disapproval I'm assuming that seasoned typists shook their head when business people started to buy computers to typeset their own documents. I'm sure they were also proven right in the early days as documents were poorly formatted or took long to produce. But, it wasn't that way for long. Any time you have a field of people that is hyper optimized on maintaining a single workflow/tool/thing it will take a lot of effort to replace. There being a large amount of effort to replace a tool does not mean it shouldn't be replaced.
mooreds 6y ago
Agree 100%. I wrote a whole post about that. https://letterstoanewdeveloper.com/2019/11/11/learn-sql/ https://letterstoanewdeveloper.com/2019/11/11/learn-sql/ In a more general sense, you have to be able to peel back abstractions. Those can include data storage abstractions, network abstractions (no, a network call isn't free, even in the same AWS AZ), and deployment abstractions like Docker.

by dkarl 6y ago

cheez 6y ago

And if you aren't convinced, SQLite (and postgres) implemented MongoDB as a feature ;-)

StavrosK 6y ago
Which should be used very sparingly, unlike the actual MongoDB, which shouldn't be used at all.
- cheez 6y ago
  haha. I use it for application plugin configuration values which allows plugins to do whatever they want but also provides some structure just in case sweeping changes need to be made. Basically where schemas aren't important or will be defined by someone else.
- jointpdf 6y ago
  I’ve heard (way) more than one story about MongoDB mysteriously annihilating all the data. Launched into oblivion. The worst imaginable outcome for a database.
  - StavrosK 6y ago
    Oh yeah, I have two of those myself.
  - cheez 6y ago
    jeebus
  - TimTheTinker 6y ago
    It's worth mentioning that MongoDB used to have a terrible storage engine--and it would do all sorts of stuff like this under stress. But it was replaced with a much better engine (WiredTiger) with write-ahead journaling and checkpoints around the year 2016.
    - jlokier 6y ago
      In 2020, MongoDB continues to fail consistency tests. "Jepsen Disputes MongoDB’s Data Consistency Claims" https://www.infoq.com/news/2020/05/Jepsen-MongoDB-4-2-6/ https://www.infoq.com/news/2020/05/Jepsen-MongoDB-4-2-6/ "MongoDB 4.2.6" http://jepsen.io/analyses/mongodb-4.2.6 http://jepsen.io/analyses/mongodb-4.2.6
  - joedrumgoole 6y ago
    I've worked at MongoDB for seven years right next to our EMEA/APAC support teams. We've never come across and instance where MongoDB was "mysteriously annihilating all the data". We would take any incidence of that whether it was a paying customer or not very seriously. If you know someone this has happened to I would encourage you to get them contact us. Joe Drumgoole Director of Developer Relations, MongoDB

eikenberry 6y ago

> Generation after generation of programmers takes one look at SQL and decides it would be more convenient to believe that relational databases don't solve any of their problems. I think this also goes toward the point of why they all do this... that SQL isn't what most developers like or want. SQL is an complex data manipulation DSL that most of the time is complete overkill for what you need and using something simpler and more specifically oriented toward your requirements makes more sense. Personally I was pretty good with SQL 15 years back but have moved on and don't regret not having needed it as the various non-RDBMS systems have more that met all my needs.

the_af 6y ago
> that SQL isn't what most developers like or want "Most" developers? That's debatable. But I can tell you a lot of people I talked to who chose MongoDB didn't have a single good reason for choosing it. For some, it's the only DB they are familiar with ("I used it before"). Others had vague, badly-argued reasons such as "the schema might change" or "it's faster to just use MongoDB". Seasoned DBAs almost always shook their heads in disapproval (and ended up being proven right).
- gravypod 6y ago
  > For some, it's the only DB they are familiar with ("I used it before") I'm sure some of the reasons you use your RDBMS of choice over another implementation or a NoSQL system distill to, at some point, "I used it before". Familiarity is a feature. This is especially true if your org invests in tooling that improves the usability of a DB. > badly-argued reasons such as "the schema might change" or "it's faster to just use MongoDB" Why are these badly-argued reasons? I currently work on a codebase that is making heavy use of MongoDB. We are using it as a way to store protobufs which will change very frequently in structure (adding new fields, removing old fields, etc). Our software is built so that it supports older versions of protos which is already needed for backwards-compatibility in APIs. Because we're using Mongo I've written a simple connector that maps our protos into Mongo that allows documents in a collection to map well into proto access semantics (default to emptiness). If a frontend developer wants to save some new field into a database they: 1. Add the field into the proto 2. Validation field in service (optional) We don't have any ops work needed. We don't have any roll forward or roll back planning needed. Since we're a really small team this flexibility afforded to us is a huge velocity boon. Since we use gRPC we push people towards not making backwards incomparable API which makes our mongo-mapper very basic. We are also planning on making use of things like `watch()` which is possible to do in some hacky ways in postgres but it's very easy to do with this architecture. I've never had as smooth an experience with PG/MySQL/SQLite, even with ORMs. > Seasoned DBAs almost always shook their heads in disapproval I'm assuming that seasoned typists shook their head when business people started to buy computers to typeset their own documents. I'm sure they were also proven right in the early days as documents were poorly formatted or took long to produce. But, it wasn't that way for long. Any time you have a field of people that is hyper optimized on maintaining a single workflow/tool/thing it will take a lot of effort to replace. There being a large amount of effort to replace a tool does not mean it shouldn't be replaced.

mooreds 6y ago

Agree 100%. I wrote a whole post about that. https://letterstoanewdeveloper.com/2019/11/11/learn-sql/ https://letterstoanewdeveloper.com/2019/11/11/learn-sql/ In a more general sense, you have to be able to peel back abstractions. Those can include data storage abstractions, network abstractions (no, a network call isn't free, even in the same AWS AZ), and deployment abstractions like Docker.