While I appreciate your sentiment here, the fact is there are situations where having the most bulletproof solution isn't the best solution.
A perfect example are, in my mind, some of the reasons why node.js is taking off as opposed to say Java or C#... One, is that the latter tend to follow "enterprise" development practices. That is, they will follow "architect" tooling that implements "design patterns" ... the problem is that this adds its' own kinds of complexity.
In C# (or Java), there are frameworks and tooling that tend to follow design patterns, which is nice. There are abstractions that allow for the use of multiple injection/ioc systems to make code more modular and testable. Which is awesome. It also makes code more complex, and the abstractions are often harder to follow.
In JavaScript, since you can replace just about anything, and even call into functions with differing contexts, this makes testing even easier. Because if this simplicity, with a module system (like commonjs/node/npm), you can write testable code without the need for the use of interface abstractions... It becomes easier to test, write for and use.
There are down sides to using JS over C# etc.. but the same arguments apply to data usage. Most "NoSQL" databases give up some safety, usually for big performance gains. It really depends on the context of the data, which I think in DBA terms is often lost. I've seen some horribly normalized datasets used in SQL to create "flexible" systems, where a NoSQL solution is a much better fit.
It depends on your needs. There are times where I'd lean more towards ElasticSearch, Mongo, Redis, Couch, Cassandra, RethinkDB and others over the likes of MS-SQL, PostgreSQL, Oracle, DB2, Firebird, etc.... all have advantages and disadvantages over eachother. An embedable db abstraction is often a very good thing. Depends on what you need.
I specifically added Firebird above, because I've used it as the core for an embedded/distributed data layer before... This was long before node.js was an option.. now, I might favor something like tfa solution, with a mongodb central db.
A perfect example are, in my mind, some of the reasons why node.js is taking off as opposed to say Java or C#... One, is that the latter tend to follow "enterprise" development practices. That is, they will follow "architect" tooling that implements "design patterns" ... the problem is that this adds its' own kinds of complexity.
In C# (or Java), there are frameworks and tooling that tend to follow design patterns, which is nice. There are abstractions that allow for the use of multiple injection/ioc systems to make code more modular and testable. Which is awesome. It also makes code more complex, and the abstractions are often harder to follow.
In JavaScript, since you can replace just about anything, and even call into functions with differing contexts, this makes testing even easier. Because if this simplicity, with a module system (like commonjs/node/npm), you can write testable code without the need for the use of interface abstractions... It becomes easier to test, write for and use.
There are down sides to using JS over C# etc.. but the same arguments apply to data usage. Most "NoSQL" databases give up some safety, usually for big performance gains. It really depends on the context of the data, which I think in DBA terms is often lost. I've seen some horribly normalized datasets used in SQL to create "flexible" systems, where a NoSQL solution is a much better fit.
It depends on your needs. There are times where I'd lean more towards ElasticSearch, Mongo, Redis, Couch, Cassandra, RethinkDB and others over the likes of MS-SQL, PostgreSQL, Oracle, DB2, Firebird, etc.... all have advantages and disadvantages over eachother. An embedable db abstraction is often a very good thing. Depends on what you need.
I specifically added Firebird above, because I've used it as the core for an embedded/distributed data layer before... This was long before node.js was an option.. now, I might favor something like tfa solution, with a mongodb central db.