It's not a matter of being negative but recognizing that known, stable software is important for continuity in the enterprise and that "new and shiny" tends to be extremely unstable and break regularly at unexpected times.
Notably, even when NoSQL came out, devs could already accomplish nearly everything NoSQL did in a traditional RDBMS way by just serializing data plus get JOINs, ACID and transaction support, and still work within a known, stable software environment. NoSQL didn't offer any of the latter critical database features - it was all beta quality at best for quite a while and NoSQL was for "at Google scale" deployments (aka only Google, Amazon, Twitter, and Facebook really needed that kind of solution). And major RDBMS vendors have already added much of what drove people to NoSQL in the first place into their products with native field types and advanced search indexes. Even Google, which started the NoSQL movement, has begun moving away from NoSQL back to SQL-driven architecture, so that says something right there:
Most of the core problems in computing were solved in the 1960s and 1970s. And that goes for SQL too. Whatever is new and shiny today was probably already solved back then but there's always someone who wants to reinvent it now so their name is on it and they can be famous (or something). SQL is broadly understood, is Standardized (e.g. ISO/IEC 9075:2016), has decades of computing behind it, and scales well enough for most needs. Those "devs who refuse to use NoSQL" probably understand all that and are simply willing to wait until NoSQL goes away.
Well said. I also found that people were driven to the NoSQLs of the world for the same reason as the JavaScripts and Pythons... No types to be concerned about.
A lot of people don't understand types, and why they matter.
But then, as more people started using it, they realized that types really do make for a better coding experience, and thus all of the above started building (among others) types into their feature set.
Similarly, transactions also weren't a thing until much later after the release of these NoSQL / DocumentDB platforms.
It's fine to learn about new platforms if they solve a problem, but don't throw existing platforms away because they're not new / flashy. If all you're getting from a new platform is "bragging rights", then you're going in the wrong direction :-D
Memcached protocol in MySQL makes a nice way of updating things using a straightforward key/value pair system too (if only it worked for their JSON data type it would be ideal for everything). We use a combination of standard SQL and JSON data in SQL with indexed columns projected out - this is the benefit of the application of NoSQL techniques to SQL in a mature product for sure - I can do a multi-table join and a report on it, I'd have a much harder time doing that in a pure NoSQL enviornment.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
It's not a matter of being negative but recognizing that known, stable software is important for continuity in the enterprise and that "new and shiny" tends to be extremely unstable and break regularly at unexpected times.
Notably, even when NoSQL came out, devs could already accomplish nearly everything NoSQL did in a traditional RDBMS way by just serializing data plus get JOINs, ACID and transaction support, and still work within a known, stable software environment. NoSQL didn't offer any of the latter critical database features - it was all beta quality at best for quite a while and NoSQL was for "at Google scale" deployments (aka only Google, Amazon, Twitter, and Facebook really needed that kind of solution). And major RDBMS vendors have already added much of what drove people to NoSQL in the first place into their products with native field types and advanced search indexes. Even Google, which started the NoSQL movement, has begun moving away from NoSQL back to SQL-driven architecture, so that says something right there:
blog.timescale.com/blog/why-sql-be...
Most of the core problems in computing were solved in the 1960s and 1970s. And that goes for SQL too. Whatever is new and shiny today was probably already solved back then but there's always someone who wants to reinvent it now so their name is on it and they can be famous (or something). SQL is broadly understood, is Standardized (e.g. ISO/IEC 9075:2016), has decades of computing behind it, and scales well enough for most needs. Those "devs who refuse to use NoSQL" probably understand all that and are simply willing to wait until NoSQL goes away.
Well said. I also found that people were driven to the NoSQLs of the world for the same reason as the JavaScripts and Pythons... No types to be concerned about.
A lot of people don't understand types, and why they matter.
But then, as more people started using it, they realized that types really do make for a better coding experience, and thus all of the above started building (among others) types into their feature set.
Similarly, transactions also weren't a thing until much later after the release of these NoSQL / DocumentDB platforms.
It's fine to learn about new platforms if they solve a problem, but don't throw existing platforms away because they're not new / flashy. If all you're getting from a new platform is "bragging rights", then you're going in the wrong direction :-D
Memcached protocol in MySQL makes a nice way of updating things using a straightforward key/value pair system too (if only it worked for their JSON data type it would be ideal for everything). We use a combination of standard SQL and JSON data in SQL with indexed columns projected out - this is the benefit of the application of NoSQL techniques to SQL in a mature product for sure - I can do a multi-table join and a report on it, I'd have a much harder time doing that in a pure NoSQL enviornment.