3 ms·

> Only because you drop data on the floor if it's inconsistent, which is rarely a good enough solution in the real world. E.g. someone tries to add a customer b

> Only because you drop data on the floor if it's inconsistent, which is rarely a good enough solution in the real world. E.g. someone tries to add a customer but the city has been deleted in the meantime -> they get an error, and the system throws away everything they input about the new customer. You end up having to implement your own dead letter queues etc. and do all the work you would with a NoSQL datastore. What. Who's letting people delete random shit out of the DB? Why is the origin of this data not validating against the actual data from the DB before sending data? "Hey we have to ensure that customers are selecting valid cities. We have a list of cities in the DB. Let's ensure we cache the cities in the api server so that we're not hitting the DB for every page load for data that will very rarely, if ever, change. Especially since we revoked Dave's DELETE permissions after that last time he deleted stuff from a production database."

lmm 5y ago
> Why is the origin of this data not validating against the actual data from the DB before sending data? It's on the client side, so it can't hold an open transaction with the server. It can validate against a previous version of the list of cities, but there's always the possibility of a delete happening in parallel. (And if your answer is to use a delete flag rather than actually deleting a row, then you're undermining the referential integrity constraints that were supposed to be the whole point of using a relational database)
- EdwardDiego 5y ago
  >It can validate against a previous version of the list of cities, but there's always the possibility of a delete happening in parallel. If a "city" is a) required attribute of an entity and b) required to exist as an entity itself, then deleting a city would require deleting all other entities that refer to that city. If city is a nullable attribute, then your validation issue you raised earlier is voided - an invalid "city" can just be replaced with null. Assuming you're wanting to delete cities, then your client side shouldn't be firing off data and assuming success. > It can validate against a previous version of the list of cities, but there's always the possibility of a delete happening in parallel. Yep, caching is hard, but your argument that "RDBMS aren't that great" is predicated on a very... ...convoluted system.
  - lmm 5y ago
    > If a "city" is a) required attribute of an entity and b) required to exist as an entity itself, then deleting a city would require deleting all other entities that refer to that city. Right, so usually what people implement (and what the database enforces by default) is that you can't delete a city if there are any customers in that city. But they don't think about what happens when two people try to make changes in parallel, because the whole point of ACID is that each query runs in its own transaction. > Yep, caching is hard, but your argument that "RDBMS aren't that great" is predicated on a very... ...convoluted system. All the use cases for referential integrity - and transactionality - are like this though. You can't actually use them for anything, not with a web app where the client can't hold a transaction open.
    - EdwardDiego 5y ago
      > All the use cases for referential integrity - and transactionality - are like this though. You can't actually use them for anything, not with a web app where the client can't hold a transaction open. You should probably tell the millions of companies actually using them for things that they're wrong. I'm sure they'll feel very silly.
      - lmm 5y ago
        The actual businesses generally don't. It's funny how RDBMS fans always say "businesses x, y and z were built on MySQL" and forget to mention that they were actually using MyISAM-based versions of MySQL that had no ACID and barely any referential integrity constraints. Most of the "mongodb is web scale" crowd is coming from the same ideology as the people who were hating on MySQL 10 years ago.
    - kaba0 5y ago
      > But they don't think about what happens when two people try to make changes in parallel, because the whole point of ACID is that each query runs in its own transaction. You do know that the D in ACID stands for consistency? That is in case a transaction try to modify something that was already changed in a parallel transaction that was already committed, it will fail and will be rolled back (given proper transaction levels). So I really don’t understand your point. Also, you can hold a transaction open for a client..

lmm 5y ago

> Why is the origin of this data not validating against the actual data from the DB before sending data? It's on the client side, so it can't hold an open transaction with the server. It can validate against a previous version of the list of cities, but there's always the possibility of a delete happening in parallel. (And if your answer is to use a delete flag rather than actually deleting a row, then you're undermining the referential integrity constraints that were supposed to be the whole point of using a relational database)

EdwardDiego 5y ago
>It can validate against a previous version of the list of cities, but there's always the possibility of a delete happening in parallel. If a "city" is a) required attribute of an entity and b) required to exist as an entity itself, then deleting a city would require deleting all other entities that refer to that city. If city is a nullable attribute, then your validation issue you raised earlier is voided - an invalid "city" can just be replaced with null. Assuming you're wanting to delete cities, then your client side shouldn't be firing off data and assuming success. > It can validate against a previous version of the list of cities, but there's always the possibility of a delete happening in parallel. Yep, caching is hard, but your argument that "RDBMS aren't that great" is predicated on a very... ...convoluted system.
- lmm 5y ago
  > If a "city" is a) required attribute of an entity and b) required to exist as an entity itself, then deleting a city would require deleting all other entities that refer to that city. Right, so usually what people implement (and what the database enforces by default) is that you can't delete a city if there are any customers in that city. But they don't think about what happens when two people try to make changes in parallel, because the whole point of ACID is that each query runs in its own transaction. > Yep, caching is hard, but your argument that "RDBMS aren't that great" is predicated on a very... ...convoluted system. All the use cases for referential integrity - and transactionality - are like this though. You can't actually use them for anything, not with a web app where the client can't hold a transaction open.
  - EdwardDiego 5y ago
    > All the use cases for referential integrity - and transactionality - are like this though. You can't actually use them for anything, not with a web app where the client can't hold a transaction open. You should probably tell the millions of companies actually using them for things that they're wrong. I'm sure they'll feel very silly.
    - lmm 5y ago
      The actual businesses generally don't. It's funny how RDBMS fans always say "businesses x, y and z were built on MySQL" and forget to mention that they were actually using MyISAM-based versions of MySQL that had no ACID and barely any referential integrity constraints. Most of the "mongodb is web scale" crowd is coming from the same ideology as the people who were hating on MySQL 10 years ago.
  - kaba0 5y ago
    > But they don't think about what happens when two people try to make changes in parallel, because the whole point of ACID is that each query runs in its own transaction. You do know that the D in ACID stands for consistency? That is in case a transaction try to modify something that was already changed in a parallel transaction that was already committed, it will fail and will be rolled back (given proper transaction levels). So I really don’t understand your point. Also, you can hold a transaction open for a client..