What are the arguments in favor of using transactions in the database?

Question

MySQL

Moved to a new job. And then it turns out that the guys do not use transactions at all (!) When writing related data. And foreign keys are not placed anywhere (!!) in the database.
To my arguments that this threatens data integrity, the answer is that integrity should be controlled at the level of the application code itself.
I kind of understand with my soul that it’s impossible to write without transactions in such cases, but here’s the killer - I don’t have any more arguments on this topic.
I would like to hear arguments along with some cases that the approach "Fuck the transaction, you need to write the correct code" is not correct.

Answer 1

"1) Add a transaction - just a few lines of code.
2) I would just like to hear what problem cases are possible here"
Write a few lines of code - developers' time and customer's money. "
Test a few lines of code - testers' time and customer's money.
Achieve creating a new task that the customer will pay for - the time of managers and the money of the customer
Using transactions is just a tool, not the truth.You need to give an example when in the current operation of your application a real error situation may arise due to the fact that you do not use transactions , and that it will be more profitable and cheaper to solve or prevent such a situation by introducing transactions than using code, as it is done now.
Look for an answer on a toaster, where they don’t know about your project, work conditions, or how easy it is to add a similar task to a sprint - it’s unlikely that you will get the right answer, there is even a chance that you will get several different answers, but you will only accept it as the correct one the one that you personally like, and not the one that is more adequate.

Answer 2

Главный аргумент за использование транзакций, это не запись связанных данных, - а корректная обработка конкурентных запросов, в тех случаях когда это критично.
Условно писать без транзакций биллинг - показатель профнепригодности, а вот какой нибудь бложик - вполне нормально.

Answer 3

Т.е. вы сами услышали где-то или "душой поняли" что транзакции МАСТХЕВ.
Начали об этом спорить с коллегами.
При этом у вас нет ни одного аргумента в их пользу?
А теперь просите чтобы мы за вас поспорили с вашими коллегами.
Вы прямо вылитый интернет-воен или диванный, не знаю есть ли разница.
По теме:
https://ru.wikipedia.org/wiki/ACID

Answer 4

Ну как бы и без транзакций можно обходиться. Например использовать поле version, которое прибавляется каждый раз при при update.
Если вся работа с данными сводится к их добавлению, то транзакции и не нужны.
Но если присутствует цикл select/update, да еще и в несколько потоков, то рано или поздно данные повредятся.
Простой случай, возьмем поле debit. Попробуем его увеличивать в несколько потоков без транцакций в цикле - select debit from mytable where ID=10, программно прибавляем единичку к полученному debit, затем делаем update mytable set debit=11 where ID=10. Результат приятно удивит.
Также можно обойтись и без транзакций (точнее использовать так называемые "оптимистические блокировки"), если с полем debit считывать, например, поле version -

select debit, version as oldversion from mytable where ID=10

. Тогда update будет выглядеть примерно так

update mytable set debit =11, version=version+1 where ID=10 and version=oldversion

. Но при этом придется всегда проверять, изменили ли мы данные или нет.
ЗЫ. По просьбам трудящихся, про оптимистические блокировки - https://ru.wikipedia.org/wiki/Блокировка_(СУБД)

Answer 5

The only thing that can be argued is that there is much less code when using the built-in features of the DB - why write something that is already well implemented in the DB?
And so, with full code coverage with tests and a normal architecture, there is not much difference. Unless writing transactions at the application level is some strange perversion. And here without foreign keys it is quite possible to manage. I always put them on, but I can understand those who give up on this.

Answer 6

Make a correct sample that "breaks" the logic, for example, a competitive request for a double write-off of the same money.

integrity must be controlled at the level of the application code itself.

How do they control it?
It is possible, but not for complex transactions.