Re:MongoDB queries don’t always return all matching documents
by orf on Wednesday June 08, 2016 @12:21PM
(#11863351)
> A number between 1 and 10 on Tuesday is only slightly different. You can say it is not arbitrary, whatever.
It's not arbitrary, because the constraints at least in Postgres are themselves constrained to validating a single row in a single table. Your app code can be truly arbitrary, you could trigger a device that posts a carrier pigeon to someone many miles away and waits for it to return with a result. That's arbitrary.
> Just in case you forgot the original claim, it was that if you use a SQL database, the constraints are in your database, but if you use mongo, the constraints are in your code.
Sorry, that's not what I was claiming. I was stating, correctly, that constraints relating to the data belong in the database. Constraints belonging to the business logic that powers your app belong in your app. You can be 100% sure that a constraint in your database will be respected, whereas the same can't be said of your apps code.
If you are given a specification that says "no username can be longer than 12 characters", that's what you add to your database constraints. A specification that says "No emails from temporary email providers are allowed" belong in your app code. Clear separation of concerns, that mongodb has no clue about. 'Just validate everything in your code, and if you get junk data in your database then I fucking hope your code can handle it'. Please.
> Therefore, saying that it is a great win that a SQL database can do some basic constraints checking
It can do pretty complex constraints. On the data. The more complex, completely arbitrary constraints belong in your app code.
> is a ridiculous argument because it hardly contributes any benefit due to the fact that even more complex constraints are in the code.
What. That makes no sense. So having 100% certainty that no column value in your database will violate any of the constraints you place on it 'hardly contributes any benefits' because... you have other, unrelated, business constraints in your app? What logic is this?
It's not arbitrary, because the constraints at least in Postgres are themselves constrained to validating a single row in a single table. Your app code can be truly arbitrary, you could trigger a device that posts a carrier pigeon to someone many miles away and waits for it to return with a result. That's arbitrary.
> Just in case you forgot the original claim, it was that if you use a SQL database, the constraints are in your database, but if you use mongo, the constraints are in your code.
Sorry, that's not what I was claiming. I was stating, correctly, that constraints relating to the data belong in the database. Constraints belonging to the business logic that powers your app belong in your app. You can be 100% sure that a constraint in your database will be respected, whereas the same can't be said of your apps code.
If you are given a specification that says "no username can be longer than 12 characters", that's what you add to your database constraints. A specification that says "No emails from temporary email providers are allowed" belong in your app code. Clear separation of concerns, that mongodb has no clue about. 'Just validate everything in your code, and if you get junk data in your database then I fucking hope your code can handle it'. Please.
> Therefore, saying that it is a great win that a SQL database can do some basic constraints checking
It can do pretty complex constraints. On the data. The more complex, completely arbitrary constraints belong in your app code.
> is a ridiculous argument because it hardly contributes any benefit due to the fact that even more complex constraints are in the code.
What. That makes no sense. So having 100% certainty that no column value in your database will violate any of the constraints you place on it 'hardly contributes any benefits' because... you have other, unrelated, business constraints in your app? What logic is this?