Any downsides to validating directly against a DB schema?

[fuzzybabybunny]

I'm running MongoDB (because I'm using Meteor and it only supports Mongo). Mongo is schema-less, but there are packages that enable me to add a schema to it.

There are also packages that can utilize the schema itself as the standard to validate any data entries against.

So based on this, are there any downsides to using the schema itself on the server for validation? To me it seems like it would be the fastest, most direct and secure way of validating...

 

[ForumMaster]

Isn't that kind of contradictory when using such a solution such as Mongo? Mongo isn't an RDBMS. it's a json store. you store documents inside. I would think that any ORM that offers validation would hamper performance significantly.

 

[fuzzybabybunny]

Isn't that kind of contradictory when using such a solution such as Mongo? Mongo isn't an RDBMS. it's a json store. you store documents inside. I would think that any ORM that offers validation would hamper performance significantly.

I think that for my humble purposes imposing a schema isn't going to be that big of a performance hit.

I'm using it more as a way to validate my forms and make sure I get correct data.

There is a package for Meteor that allows me to, for instance, on my schema set a key in my database as required and which has an integer value. On the front end I can then check for the existence of this entry and for the proper type, all in the form itself and according to the schema and only the schema, thus doing a client-side and server-side validation all in one line of code and from one single "source" of validations.

 

[Ken g6]

I think that for my humble purposes imposing a schema isn't going to be that big of a performance hit.

Just using Mongo is a big performance hit, before you add a schema on top of it. Why not use a real RDBMS like MariaDB? Are you doing some stuff that's actually better done in Mongo?

As for validation, sending data to the DB should be the last step you do. Edit: For serious discussion, see https://en.wikipedia.org/wiki/SQL_injection

 

[ArsDiaboli]

Just use Meteor's Check function.

 

[Cerb]

Just using Mongo is a big performance hit, before you add a schema on top of it. Why not use a real RDBMS like MariaDB? Are you doing some stuff that's actually better done in Mongo?

Using something that uses Mongo only, and thus using Mongo. Though, MySQL would be terrible for what the OP proposed, as check constraints are ignored (PostgreSQL FTW: fewer and less complex triggers).

As for validation, sending data to the DB should be the last step you do. Edit: For serious discussion, see https://en.wikipedia.org/wiki/SQL_injection

And even then, parameterize everything, everywhere you can.

If you have transaction safety, which is iffy on Mongo (I've only got docs and howtos, as I've never been in a situation where Mongo looked like anything but a way to increase the hours I would need to get anything done), then it can be handy. Without that, though, you'll likely have to make faux-transactions client-side (from Mongo's PoV), at which point it would likely be easier to check correctness well before commit attempts. Even with a solid DB, checking against the DB by trying to write it is going to cause CPU/disk spikes that an be avoided by not doing it.

If you need transaction-like behavior, you should probably add time-stamped metadata, like a value for, "form X was made on Y," and, "form X passed type/relationship/value checks on Z," so that you at least don't have unknown incorrect/orphan data at any point (a DB should only store truths, so if you scrub for them, data not matched with the full set of that metadata might not be true, and should thus be repaired or discarded).

If you're not storing prepared data, already checked for correctness and form, a basic K/V document store is not likely a good back-end, unless the data itself is largely of little importance.