Because people hate the constraints put in place by SQL. It doesn't really matter that they'll spend dozens of hours re-implementing stuff they would've gotten for free with SQL in a RDBMS (not to mention the benefit of serious stability), what matters is that the initial effort to make a change is much lower, and thus developers feel like they're saving a lot of time/hassle. They don't seem to connect the cost on the backend with its cause, or they just don't mind it.
With NoSQL you do have to reimplement all of the constraints in the application but this will likely be necessary even for SQL code because you'll need to provide both server and client side validations on user input.
SQL can be even more of a pain because you'll need additional checks to handle the SQL server's particular blend of error handling if/when something goes wrong.
In both SQL and NoSQL, any decent ORM should provide models, validations, sane error handling, and constraint checks so none of those really matter.
Unless, for whatever reason the business logic is defined in SQL SPROCS. Then, good luck if/when they don't work properly.
Why would an SQL ORM provide validations? The database itself already does.
Additionally, user data isn't the only data that needs to be validated. The vast majority of our data is generated by the program itself, and schemaless databases have given us endless headaches with this.
Client-side validation are much more important that server-side validations.
Preventing a user from sending bad data to begin with avoids the poor usability of having to send bad a failed request and reset the form for editing.
Database constraints only avoid bad data in the database. They still have to be duplicated for error checking in the server and client.
Is JS is used on both the server and client, it makes a lot more sense to have ORM models that act as the single source of truth for structure (ie model/schema), condtraints, testing, and validations.
Issues with unstructured data come either from laziness (ie not using schemas in production code) or mismanagement (ie not handling migrations properly between schema changes).
Having the ability to use completely schema-free, unstructured data doesn't mean schema/validations should be ignored altogether.
You wouldn't blame the gun if you shot yourself in the foot, would you?
ORM or not, you still need constraints in the database, though.
There may be more than one client connecting to the database at the same time (or even internal inconsistencies within the same process), and the only way to prevent data inconsistencies is to hand the final responsibility of validation to the thing that is actually storing the data, ie. the database.
In the end, your database is the single source of truth, as it is the only part of your architecture that is technically capable of doing so. Client-side validation and server-side validation (in the application) are niceties for UX purposes, but do not and cannot replace database constraints.
>You wouldn't blame the gun if you shot yourself in the foot, would you?
If it was unreasonably easy to do so, then yes. This is why there are gun safeties. The phrase "hairpin trigger" or "hair trigger" derives from guns with light triggers that made a premature or accidental discharge too easy.
"A poor workman blames his tools" only works if you have real tools. It's OK to blame tools when you're forced to use a twig as a hammer.
It's not that you don't have migrations, it's that you move that logic to your application code. I personally find that to be a terrible trade-off. People make the same arguments in favor of mutable data structures: you benefit initially from having everything mutable, but then you start writing code to compensate for the flexible nature of it and suddenly you have a whole new set of issues.
Migrations don't actually take more time than defining the schema implicitly in your application, and you don't even need to think about joins at all if it's only going to be a prototype.
MongoDB is far from "simple to work with". This is 100% marketing bullshit (along with dubious claims like it being "fast" when it never has been), trotted out by MongoDB's marketing department. Let's not forget that it has always been a commercial project.
EDIT: And to clarify, relational databases and document stores are not interchangeable. You need to pick the one that reflects your data model most accurately.
Usually that's going to be "relational", sometimes it will be "documents" - but even if it is, there are better options than MongoDB.
Not only prototyping. If the final product will have a moderate amount of users generating a moderate amount of data, there is really no drawbacks with mongoDB. The real cost is development time.
Of the mongoDB projects I've been involved with, I've always wanted to do large complex joins and filters which was just didn't perform as well as relational databases, and there is no support (as far as I know) for geo-coded data.
That's why I suggest it's good for prototyping, maybe it will work for some projects long-term, but I don't think it's the norm as mongoDb would suggest.
However, most prototypes don't end up as successes, so that's where I figure it's worth the switching cost once a go-nogo decision is made.
It's a completely fallacious argument. Using MongoDB doesn't save you time, it just shifts the effort towards a later point, where it will require several times as much effort to fix shit, which may not even succeed and you may end up with corrupted data.
I use MongoDB because I can instantly save down a JavaScript object and later retrieve it in the same state. I don't have to worry about anything else. No configuration, nothing. That's all I need but if there are better options I'm all ears.
You're not "saving down a JavaScript object", as MongoDB does not speak JavaScript. What you're doing is passing an object to your database driver, which then converts it to JSON, and sends it to MongoDB.
JSON is an entirely separate language from JavaScript, and it can be used from just about any language. This "convert a native object into the query format" thing is also literally what almost every database driver in almost every language does.
This has precisely zero to do with either MongoDB or JavaScript.
Ok, so I'm saving it down as a JavaScript Object Notation which looks exactly the same as JavaScript. I think that's very convenient and don't see how it's the same as converting for example PHP to MySQL where I'm bound by a schema which looks nothing like my data structure in PHP.
Aside from that, if you want a native nested representation of data in your database, so including relations, you use an ORM. For example, in PHP with MySQL, you might use Eloquent.
How data is represented in your application and how it's represented in the database, are two entirely different things. There's no advantage to be gained from trying to make them the same thing - that's the concern of the database abstraction that you choose to use.
It's not irrelevant for me. When I look at a record in my database it looks the same as when defining it in code. This is a big advantage for me. Using an ORM is way more complicated than just inserting/retrieving my JS object. As I said, I don't want to configure stuff. I just want to save the object and be able to retrieve it by some key in the object.
It's nice with zero configuration. Especially the no password by default thing. Why bother with limiting your database with host access and passwords ;)
I use environment variables so the configuration is basically setting up the host/username/pw in the Heroku interface. But ok, almost no configuration then...
MongoDB plays very well with the rest of the javascript based stack, which mean development and testing is simpler. For many use cases the development time is the real cost, and the database itself is simple enough that what it is running on does not really matter much.
Mongo isn't even "Javascript-friendly". It just accepts JSON for queries, that's all. JSON is approximately as related to Javascript as Javascript is related to Java.