I quoted "developers", because we need a term to distinguish people who know basic computer science from people who know just enough to install software and piece together APIs. The latter group tends not to realize that things like overwriting your working set in memory and global write-locking lead inevitably to consistency and throughput issues.
The primary problem in software today is that we've confused the ability to build something with actually knowing anything of value.
we've confused the ability to build something with actually knowing anything of value
Am I reading this correctly? It seems to imply that the ability to build something is somehow orthogonal to knowledge of value.
I don't know about throwing mud into a heap and then calling it sculpture, but if we are talking about the subset of "things" that have value in and of themselves, the ability to build them does imply some knowledge of value.
Now, the relative value of knowing how to put together simple web sites using jQuery vs. the knowledge to discover Chaitin's Constant is very much worthy of discussion. But likewise, the knowledge of how to construct a true but unproveable statement in a toy system vs the knowledge of how to build VisiCalc and revolutionize programming is worthy of discussion as well.
"Am I reading this correctly? It seems to imply that the ability to build something is somehow orthogonal to knowledge of value."
Not only are you reading it correctly, that is in fact (part of) what I'm saying. Building something doesn't automatically create value. We've confused the two.
In the real world though, both groups still need to use what works in practice. It's entirely possible for MongoDB to work sufficiently well for a certain group of people in a reasonably cost effective way. Exaggerating its problems (as bad as they are) doesn't add weight to your agrement. For example, global write-locking will not _inevitably_ lead to consistency or throughput unless the write frequencies are sufficient to cause and require that. Lots of data problems aren't "big data", they're barely a medium.
I'll agree MongoDB is not a terribly well engineered database however I don't agree that SQL is always the best alternative in these simpler scenarios. There are lots of things wrong with using SQL to solve every data problem. I also don't agree that knowing SQL is equivalent to understanding "set theory". I've known plenty of DBAs who don't know the first thing about set theory and really just know just enough to install the software and piece together the APIs. The fact that one has chosen SQL doesn't make them good at working with data any more than choosing MongoDB makes someone bad, or implies they don't understand "set theory".
What concerns me mostly though isn't the MongoDB issue but that we can't discus the issue in a professional way, without elitism and distain dripping through. You seem to have confused "computer science" with "anything of value". I happen to believe there are more things worth knowing that are of value to practical software development than just the computer science (not to minimize that of course).
SQL isn't the alternative, it's the standard and noSQL databases are supposed to offer extra value to cause you to migrate. According to these articles, MongoDB doesn't offer any real additional value, thus you shouldn't use it.
It's not about elitism, it's about making good decisions. That said, given all the hype with companies that hire, protesting loudly might not be the best short term personal decision. Meh.
I wasn't specifically talking about the articles, just in general point that'll I'm happy to stand behind. I'll happily repeat it: unless you have a specfic use case, RDBMS is the default and it should be so. Now if you have a specific use case, fair enough, but the aforementioned examples don't honestly seem to be valid reason to throw our the advantages of RDBMS.
> In the real world, people have been using relational databases to solve problems for years. They work, they're understood, they scale.
And they're a pain the ass and don't mix well with the kinds of programs many want to write. Mongo clearly fills a niche that relational databases don't serve well; if it didn't, no one would use it.
I think it's not a fight. RDBMS has been there for many years and they have proved to work in many areas. NoSQL databases born for new needs people was asking to have in their new projects.
Both would probably works perfect for many cases, but nosql databases are very suitable for scenarios when you do not require an strict schema, and also they are simple to setup.
I still think MongoDB is great for many applications as many companies are using it for their data needs (like Foresquare), and the same with RDBMS like MySQL, that lot of big fishes use them for different parts of their architecture (facebook, twitter, etc).
In the end, each option has pros/cons, but one will be better for your use case.
Could you actually go into some detail about these mythical problems with actual databases? Faux database apologists seem to really love claiming databases are so unusable, but I've never gotten an actual explanation as to what problems they are having. As both a developer and a sysadmin, postgresql is much less of a pain in the ass than mongodb. And I have no idea what "don't mix well with the kinds of programs.." is supposed to mean.
The idea that "it must be good for something or people wouldn't use it" is absurd. People do the wrong thing all the time. People make technical decisions based on fads constantly. Mongodb is one of the prime examples of fad driven development choices, where people choose it because "it is web scale" while having no idea what they are even supposed to be comparing it to.
> Faux database apologists seem to really love claiming databases are so unusable
You really think tossing out insults like that is a way to have a reasoned conversation? I think not, come back when you can converse like an adult.
> And I have no idea what "don't mix well with the kinds of programs.." is supposed to mean.
Then you need more experience as a programmer perhaps. I'm a programer and a SQL guy, and I'm fully aware of what a pain SQL can be in an application and if you don't see the ease of programming things like NoSQL databases or Mongo bring to programming, you aren't paying attention or you're lying to yourself about how well SQL fits with code.
It depends upon the application, He is right and you also are right for the feilds of programming and applications you do, gets down to pro's and cons of types of interface to the database depending upon the application at hand. We all know the variations of those. Though perhaps could of been toned right. You are just going to argue over differing types of application without saying which type.
In short you are both right, applications and also use of said applications and requirments make the difference as to what interface is best. Don't need to argue over that without even stating it. You both win, this is the internet - now laugh :).
You made baseless assertions, and provided nothing to back them up. Your comment got precisely the response it deserves. Acting indignant does not support your assertions.
The fact that you have some unspecified problem does not mean anyone else who does not have that problem is inexperienced. Given the complete lack of information available, it is just as reasonable to conclude that you are in fact lacking in experience which allows others to solve the problem you continue to refuse to define.
+1 though your both right depending on the applicatiton and with that you will go from your experience and both be right without specifying in detail an example and neither of you want to go down to doing specs on a forum to win a argument that you both will win and end up arguing about the applicaiton and specs.
I say payroll databases at dawn, 50 paces each, turn and shoot. Go :-)
And which assertion was that; the one that Mongo fits a niche which it obviously does, or the one that many people find relational databases a pain, which they obviously do. Neither of those require me to provide evidence, they are self evident facts to anyone with even moderate experience in the field. I don't have an unspecified problem, not once did I even mention a problem, so take your childish argumentative b.s. somewhere else.
Both of them. You only wrote two sentences, it shouldn't be hard to find them.
>the one that many people find
You didn't say anything about "many people find". You said they are a pain in the ass, and don't mix well with the applications many people are writing. Those are both assertions, and you supported neither of them. Even after replying twice, you still haven't even given a hint as to what you might be referring to. That really makes it seem like you are just saying things out of ignorance.
> You didn't say anything about "many people find". You said they are a pain in the ass
I said they were a pain in the ass for the kinds of programs many people want to write. I'm sorry you're too ignorant to grok my meaning without it being explained to you like a five year old child.
> Those are both assertions, and you supported neither of them.
They are self evident facts and don't require supporting evidence; the very fact that a community exists around these products should make that clear to you.
In any case, it's absolutely clear there's no value in conversing with you, good day.
>I said they were a pain in the ass for the kinds of programs many people want to write
And refuse to specify what those kinds of programs might be. You are inventing a "many" and giving them a problem to create a false impression of consensus, when it is actually just you making a singular, baseless assertion.
>the very fact that a community exists around these products should make that clear to you.
I address that in the first post. You keep responding purely to act like a petulant child, but provide absolutely nothing to support your claims. Do you really think that makes you appear to be the rational, logical party?
OTOH, I've experienced a lot of people who know basic computer science but don't grasp any software engineering. Nor do they even realize that it's a thing.
Those sorts of people tend to be very focussed on clever algorithms and data structures, and frequently miss the larger picture and coding best practices. I've seen far too much code that had extensive CS cleverness at the root but was spaghettified, untested, undocumented, poorly performant, and not even tracked in a version control system. Such people often don't value writing code that other developers can read and maintain. On a team, clarity matters more than cleverness.
The primary problem in software today is that we've confused the ability to build something with actually knowing anything of value.