Какие аргументы в пользу использования транзакций в бд?

Question

[shamyyl]

Перешел на новую работу. И тут выясняется, что ребята совсем нигде(!) не используют транзакций при записи связанных данных. И внешних ключей нигде(!!) в бд не ставят.

На мои аргументы, что это угрожает целостности данных отвечают, что целостность должна контролироваться на уровне кода самого приложения.

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

Хотелось бы услышать аргументов вместе с какими-нибудь кейсами, что подход "Нафиг транзакции, надо писать правильный код" не верен.

Answer 1

[Saboteur]

"1) Добавить транзакцию - всего несколько строк кода.
2) Как раз таки хотелось бы услышать, какие кейсы проблем здесь возможны"

Написать несколько строк кода - время разработчиков и деньги заказчика."
Протестировать несколько строк кода - время тестировщиков и деньги заказчика.
Добиться создания новой таски, которую оплатит заказчик - время менеджеров и деньги заказчика

Использование транзакций это просто инструмент, а не истина. Вам нужно привести пример, когда в текущей работе вашего приложения может возникнуть реальная ситуация с ошибками, связанная с тем, что вы не используете транзакции, и что решить или предотвратить такую ситуацию при помощи внедрения транзакций - будет выгоднее и дешевле, чем при помощи кода, как это сделано сейчас.

Искать ответ на тостере, где не знают ни про ваш проект, ни условий работы, ни того, насколько легко добавить подобную задачу в спринт - вряд ли вы получите правильный ответ, есть даже вероятность что вы получите несколько разных ответов, но за правильный примете только тот, который лично вам по душе, а не тот, который более адекватный.

Comments

[Владимир]

Первый разумный ответ

Answer 2

[Станислав Макаров]

И тут выясняется, что ребята совсем нигде(!) не используют транзакций при записи связанных данных. И внешних ключей нигде(!!) в бд не ставят.

Либо какие-то просветленные, либо дети NoSQL-эры. Скорее всего второе.

На мои аргументы, что это угрожает целостности данных отвечают, что целостность должна контролироваться на уровне кода самого приложения.

Да, должна контроллироваться на уровне приложения. Но в большинстве случаев это не повод отказываться от внешний ключей и прочих средств контроля целостности. Да, я видел, что некоторые вендоры НЕ используют ограничения целостности в релизных версиях продуктов, но это скорее исключение, чем правило. И да, самое главное - в большинстве случаев данные живут дольше, чем приложение, с ними работающее. Или - также не редкость - приложений, работающий с одной базой - несколько. Тогда вам рано или поздно захочется дополнительный уровень "доверия", т.е. контроля целостности. Вы должны понимать, что неконсистентные данные в базе - это как правило большой или очень большой гемор, т.к. после появления таких данных в базе очень непросто понять, что они там делают, и что ВАМ теперь с ними делать.
Ограничения целостности снимают только если они заметно снижают производительность БД, её (производительности) не хватает, других способов быстро поправить ситуацию нет, и у вас на данный момент уже есть хоть какая-то уверенность, что приложение не накосячит в БД.

А теперь последнее. Целостность данных - не единственное, и даже не главное, для чего нужны и полезны транзакции. Дмитрий Энтелис классно написал про профнепригодность: попросите своих коллег написать биллинг кому-нибудь, выкатить его в продакшн, а потом объяснить начальнику отдела и директору, почему у некоторых клиентов, купивших две услуги по 500, списалось только за одну услугу. Можете рассказать коллегам про уровни изоляции - тут кстати навалом примеров.

Comments

[Иван]

Может их проект изначально рассчитан на масштабирование через partitions или шардирование по какому-то признаку, и они не могут гарантировать транзакционность на уровне бд просто потому что и сама бд этого не может.
Нужно сперва знать больше деталей о проекте и кто вопрос задает, а так может быть миллионы разных ПРАВИЛЬНЫХ советов.
И спрашивающий может просто 1 из обычных разработчиков, которому не видны решения тим-лидов и архитекторов разного уровня.

[Станислав Макаров]

Иван да, вы правы, CAP никто не отменял).

Человек просил "аргументы" - он их получил. Между "аргументами" и "решением" путь довольно долгий). Тем более, судя по содержимому вопроса, все решения на счёт транзакций уже были приняты ранее, а ребята просто похоливарить решили)

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

Answer 3

[Дмитрий Энтелис]

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

Comments

[Владимир]

При желании это можно контролировать и в коде, вопрос только в затратах на те вещи, которые вы озвучили.

[Станислав Макаров]

Владимир если вы хотите контроллировать в коде (вместо использования транзакций) параллельное изменение данных из нескольких параллельных сессий с БД, то тогда вам придётся отказаться от многопользовательского функционала СУБД и пользоваться ей в стиле SQLite. И весь многопользовательский доступ реализовать уже внутри самого приложения. Ну или другой варинт - работать только с помощью блокировок, как это делали файловые БД типа FoxPro. Вы уверены, что хотите предложить автору вопроса вернуться назад в 90-е? :) Или это сугубо теоретическое замечание?

[Владимир]

Станислав Макаров: Я использую транзакции, я обожаю длинные оракловые транзакции, я знаю про уровни изоляции, но, спор о применимости транзакций - пустой треп если он не привязан к задаче, и все разговоры о крутости транзакций без привязки к Т.З. равнозначны маханию членами. Чтобы доказывать с пеной у рта о том, что без транзакций жизни не будет, нужно знать контекст, которого автор вопрос не предоставил.

[Иван]

Станислав Макаров: как будто на уровне приложения транзакционность не может быть реализована. Нужно ж из задачи исходить, а не из опыта работы с MySQL.

Answer 4

[Александр Аксентьев]

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

По теме:
https://ru.wikipedia.org/wiki/ACID

Comments

[shamyyl]

Нет, в своей предыдущей работе всегда использовал транзакции при записи связанных данных.
Свои аргументы в пользу этого я описал в вопросе.
С концепцией ACID знаком.
Если вы считаете, что я не прав, то готов выслушать ваши аргументы по этому поводу

[Владимир]

shamyyl: Киллер аргументы 1) Количество строк кода 2) Количество часов на решение проблем
Сравните, разберите кейсы. Если они выиграют, они правы.

[shamyyl]

Владимир: 1) Добавить транзакцию - всего несколько строк кода.
2) Как раз таки хотелось бы услышать, какие кейсы проблем здесь возможны

Answer 5

[Алексей Черемисин]

Ну как бы и без транзакций можно обходиться. Например использовать поле 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/Блокировка_(СУБД)

Comments

[Александр Аксентьев]

глупости пишете

[Алексей Черемисин]

Александр Аксентьев: Агрументируйте

[Александр Аксентьев]

Алексей Черемисин: про "поле version". Транзакции вообще не про это. Что вам даёт это поле кроме счетчика сколько раз вы меняли данные?

[Алексей Черемисин]

Александр Аксентьев: Про оптимистические блокировки не читали? Я подскажу. Update произведется только в том случае, если поле version после select никто не увеличил. Это также очень хорошо рабоает, например в "распределенных" или "длинных" транзакциях. Жду комментариев, с нетерпением.

[Алексей Черемисин]

Александр Аксентьев: И до кучи, как по вашему реализуются "транзакции" во многих nosql решениях?

[Александр Аксентьев]

Алексей Черемисин: не читал/не сталкивался ни разу, сразу вы про это не написали(или я пропустил мимо глаз скобки?), поэтому выглядит это очень странно и не в тему.

[Алексей Черемисин]

Александр Аксентьев: Скобки и объяснение добавил я позже, мой промах. Думал, что и так понятно.

[Александр Аксентьев]

Алексей Черемисин: Тогда ясно. Если бы я встретил незнакомый термин сразу бы ушел в гугл :)

Answer 6

[Алексей Уколов]

Единственное, что можно возразить, это то, что при использовании встроенных возможностей БД гораздо меньше кода - зачем писать то, что уже хорошо реализовано в БД?
А так, при полном покрытии кода тестами и нормальной архитектуре, большой разницы нет. Разве что писать транзакции на уровне приложения - это какое-то странное извращение. А вот без внешних ключей вполне можно обойтись. Я их всегда ставлю, но могу понять тех, кто на это забивает.

Comments

[shamyyl]

На уровне приложения реализованы не транзакции, а проверка на валидность вводимых данных.
Однако такая проверка не спасет вас от какого нибудь CRASH_RECOVERY - в этом случае целостность ваших связанных данных будет нарушена

Answer 7

[lega]

Сделайте корректный семпл который "ломает" логику, например конкурентный запрос на двойное списание одних и тех же денег.

целостность должна контролироваться на уровне кода самого приложения.

Как они это контролируют?
Можно, но не для сложных транзакций.