3 ms·

Tl:dr - you used a crappy ORM and now think all ORM libraries sick. So... use MongoDB... which is always accesses through an ORM... All your comments come acro

by orf 10y ago

Tl:dr - you used a crappy ORM and now think all ORM libraries sick. So... use MongoDB... which is always accesses through an ORM... All your comments come across as confused mate. Enforcing arbitrary constraints belongs in the business logic of your app, but dealing with consistency issues does not. Postgres handles row constraints just fine, you can enforce any arbitrary logic (i.e colX != colY and its not the first Tuesday of the month), combined with stuff like expression indexes, json type and actual schemas leaves me confused as to why you would advocate mongo so hard. Just because you write your migrations in a language like JavaScript doesn't mean it's any better than pure SQL.

1879325238 10y ago
Mongodb isn't always accessed through an ORM. I have no idea what you are talking about. > Enforcing arbitrary constraints belongs in the business logic of your app Oh so you have some constraints enforced in your database, like the length of a strength can't be greater than 5, yet others you consider arbitrary just because they are not in SQLs list of constraints? How on earth did you define arbitrary otherwise? Anyway, that is the entire point, SQL's constraints don't encapsulate all of the constraints, so you STILL HAVE TO MANAGE MANY CONSTRAINTS IN THE CODE. I hope you got it that time.... > but dealing with consistency issues does not Yes that is why I said you have to deal with consistency issues in Mongo. I then referred to consistency in another context, which was confusing, I understand. I was referring to consistency on a higher level, in terms of an entry called "Can't be deleted", with a Deleted flag set to true. Which is not related to the data consistency I was referring to earlier in the paragraph. That does not invalidate any of my arguments, you just wish it did.
- chris_wot 10y ago
  What do you mean by consistency? Something tells me you aren't using it in the way most of us understand it...
- 1879325230 10y ago
  What do you mean what do I mean? I just gave you an example. You don't seem to understand that "consistency" in a database, is simply defined within the realms of the database itself. It isn't a universal concept of "consistency". It refers to the fact that the database will enforce certain constraints and checks. You can even denormalise your data and make it so that a persons name is different in different places. My whole point, which none of you are able to grasp because you aren't programmers, is that there are MORE CONSTRAINTS then there are options available for constraints in SQL. There are business constraints that lead to "consistency" in the real-world usage of the term, issues. Consistency in database terms is limited by the types checks the database performs. Someone earlier said you can write any types of checks you want because pgsql supports writing constraints in any programming language you want. This does not counteract my point which was to refute the original comments proposition that IN MONGODB YOU HAVE TO WRITE YOUR CONSTRAINTS IN THE CODE AND THAT IS NOT THE CASE WITH SQL. Jesus guys, you are slow learners.
  - chris_wot 10y ago
    Your code enforces consistency and detects when a transaction fails the consistency rule rolls back the changes to the state when the transaction started? That's some great code I'm sure, but a lot of effort. The only limitation on an SQL check constraint is that you cannot use columns in other tables. As has been pointed about by many of us slow learners, it's far easier to understand constraints in SQL than it often is to dive into a code base.
  - orf 10y ago
    > IN MONGODB YOU HAVE TO WRITE YOUR CONSTRAINTS IN THE CODE AND THAT IS NOT THE CASE WITH SQL. You moron, that's not a good thing.
    - dang 10y ago
      Please don't respond to a bad comment by making the thread still worse.
- orf 10y ago
  You're replies in the comments are rude and borderline fanatical in tone. There are two classes of constraints: one being 'this string shouldn't be longer/shorter than x' or 'this value should only be between 1 and 10'. The other kind is 'on the first Tuesday of every month only during a full moon can this record be deleted, and only by a user with permission X'. The first can easily be modelled in SQL, the second should be modelled in your app. The first are not arbitrary, the second are. Not hard to comprehend mate. Just because SQL can't model all constraints doesn't mean you should throw it out the window and reach for mongo. Comments like 'none of you understand this because youre not programmers and therefore know nothing' is incredibly insulting. I'm of the opinion that you know nothing, and if you're happy knowing nothing with fellow mongodb users then so be it. Just keep your nonsense away from me thanks.
  - 1879325272 10y ago
    This is just a semantics argument which is boring. A number between 1 and 10 on Tuesday is only slightly different. You can say it is not arbitrary, whatever. You have just proved my point. 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. I refuted this by saying that the constraints are also in the code in a SQL database. You have proven the point even further by highlighting that they are even more complex than the constraints in the database. Therefore, saying that it is a great win that a SQL database can do some basic constraints checking is a ridiculous argument because it hardly contributes any benefit due to the fact that even more complex constraints are in the code. So you have not actually contributed anything and I never said you should throw out SQL just because it can't model every constraint. Nice strawman. You lose the argument though right?
    - orf 10y ago
      > 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?

by orf 10y ago

1879325238 10y ago

Mongodb isn't always accessed through an ORM. I have no idea what you are talking about. > Enforcing arbitrary constraints belongs in the business logic of your app Oh so you have some constraints enforced in your database, like the length of a strength can't be greater than 5, yet others you consider arbitrary just because they are not in SQLs list of constraints? How on earth did you define arbitrary otherwise? Anyway, that is the entire point, SQL's constraints don't encapsulate all of the constraints, so you STILL HAVE TO MANAGE MANY CONSTRAINTS IN THE CODE. I hope you got it that time.... > but dealing with consistency issues does not Yes that is why I said you have to deal with consistency issues in Mongo. I then referred to consistency in another context, which was confusing, I understand. I was referring to consistency on a higher level, in terms of an entry called "Can't be deleted", with a Deleted flag set to true. Which is not related to the data consistency I was referring to earlier in the paragraph. That does not invalidate any of my arguments, you just wish it did.

chris_wot 10y ago
What do you mean by consistency? Something tells me you aren't using it in the way most of us understand it...
1879325230 10y ago
What do you mean what do I mean? I just gave you an example. You don't seem to understand that "consistency" in a database, is simply defined within the realms of the database itself. It isn't a universal concept of "consistency". It refers to the fact that the database will enforce certain constraints and checks. You can even denormalise your data and make it so that a persons name is different in different places. My whole point, which none of you are able to grasp because you aren't programmers, is that there are MORE CONSTRAINTS then there are options available for constraints in SQL. There are business constraints that lead to "consistency" in the real-world usage of the term, issues. Consistency in database terms is limited by the types checks the database performs. Someone earlier said you can write any types of checks you want because pgsql supports writing constraints in any programming language you want. This does not counteract my point which was to refute the original comments proposition that IN MONGODB YOU HAVE TO WRITE YOUR CONSTRAINTS IN THE CODE AND THAT IS NOT THE CASE WITH SQL. Jesus guys, you are slow learners.
- chris_wot 10y ago
  Your code enforces consistency and detects when a transaction fails the consistency rule rolls back the changes to the state when the transaction started? That's some great code I'm sure, but a lot of effort. The only limitation on an SQL check constraint is that you cannot use columns in other tables. As has been pointed about by many of us slow learners, it's far easier to understand constraints in SQL than it often is to dive into a code base.
- orf 10y ago
  > IN MONGODB YOU HAVE TO WRITE YOUR CONSTRAINTS IN THE CODE AND THAT IS NOT THE CASE WITH SQL. You moron, that's not a good thing.
  - dang 10y ago
    Please don't respond to a bad comment by making the thread still worse.
orf 10y ago
You're replies in the comments are rude and borderline fanatical in tone. There are two classes of constraints: one being 'this string shouldn't be longer/shorter than x' or 'this value should only be between 1 and 10'. The other kind is 'on the first Tuesday of every month only during a full moon can this record be deleted, and only by a user with permission X'. The first can easily be modelled in SQL, the second should be modelled in your app. The first are not arbitrary, the second are. Not hard to comprehend mate. Just because SQL can't model all constraints doesn't mean you should throw it out the window and reach for mongo. Comments like 'none of you understand this because youre not programmers and therefore know nothing' is incredibly insulting. I'm of the opinion that you know nothing, and if you're happy knowing nothing with fellow mongodb users then so be it. Just keep your nonsense away from me thanks.
- 1879325272 10y ago
  This is just a semantics argument which is boring. A number between 1 and 10 on Tuesday is only slightly different. You can say it is not arbitrary, whatever. You have just proved my point. 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. I refuted this by saying that the constraints are also in the code in a SQL database. You have proven the point even further by highlighting that they are even more complex than the constraints in the database. Therefore, saying that it is a great win that a SQL database can do some basic constraints checking is a ridiculous argument because it hardly contributes any benefit due to the fact that even more complex constraints are in the code. So you have not actually contributed anything and I never said you should throw out SQL just because it can't model every constraint. Nice strawman. You lose the argument though right?
  - orf 10y ago
    > 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?