4 ms·

> 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

> 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.
- eikenberry 6y ago
  I'm not 100% on "most"... but really most devs I've met prefer the NoSQL options and the devs who did really like RDBMSs seemed to eventually drift into DBA positions. I'm not sure why you focused on Mongo... it is probably the poster child for a bad example of NoSQL. It focused on features and performance while leaving data integrity on the floor. Never understood it's success given its Jepsen reviews. NoSQL excels when it is targeted. Like using Etcd for config management. Consul for discovery. Redis for shared, in-memory data structures. Cassandra for high throughput, write heavy systems. DynamoDB for no-ops, key-value storage. S3 for key-value storage with large storage reqs. Etc.... They don't do as well, like Mongo, when they try to be general purpose. RDBMSs rule the jack-of-all-trade-master-of-none zone.
  - the_af 6y ago
    You have a point. I focused on MongoDB because it's indeed used for general purpose, where it doesn't fare very well and often ends up requiring hand-coded solutions to problems RDBMS solve out of the box.

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.
eikenberry 6y ago
I'm not 100% on "most"... but really most devs I've met prefer the NoSQL options and the devs who did really like RDBMSs seemed to eventually drift into DBA positions. I'm not sure why you focused on Mongo... it is probably the poster child for a bad example of NoSQL. It focused on features and performance while leaving data integrity on the floor. Never understood it's success given its Jepsen reviews. NoSQL excels when it is targeted. Like using Etcd for config management. Consul for discovery. Redis for shared, in-memory data structures. Cassandra for high throughput, write heavy systems. DynamoDB for no-ops, key-value storage. S3 for key-value storage with large storage reqs. Etc.... They don't do as well, like Mongo, when they try to be general purpose. RDBMSs rule the jack-of-all-trade-master-of-none zone.
- the_af 6y ago
  You have a point. I focused on MongoDB because it's indeed used for general purpose, where it doesn't fare very well and often ends up requiring hand-coded solutions to problems RDBMS solve out of the box.