Why MongoDB?
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.
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.
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?
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.
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.
http://blogs.tedneward.com/post/the-vietnam-of-computer-scie...
It's not for every project, but quite nice for prototyping.
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.
It's really not worth it.
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.
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.
Whether it looks the same is irrelevant. It doesn't even have the same syntax rules. For example, this is valid JavaScript:
{
one: "two",
three: undefined
}
> 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
And in 99% of cases, this is a feature, because you can't represent most data as a flat list of nested objects. See also this article: http://www.sarahmei.com/blog/2013/11/11/why-you-should-never...
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.
You still have a server to run, auth to check, etc...
Here's a real database with no configuration, no nothing, actual real plug-and-play:
Most people are not building Big Data systems.
It has very good integration with Hadoop, Spark etc.
Every major database does. This is in no way exclusive to MongoDB.