[cookiecaper]

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.

[EvanPlaice]

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.

[lucio]

Like ORM, NoSQL looks as a good decision at the beginning...

http://blogs.tedneward.com/post/the-vietnam-of-computer-scie...

[StavrosK]

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.

[EvanPlaice]

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?

[joepie91_]

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.

[cookiecaper]

>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.