Комментарии 3
Все это в свою очередь должно гарантировать целостность данных. Но что это вообще такое и на что влияет? А ответ очень простой. Обеспечивая целостность данных, мы предупреждаем ситуации, когда, к примеру, деньги со счета списались, но получателю так и не пришли. Или заказ оформился, а складские остатки не обновились.
Обычно попытка объяснить общее частными примерами - это либо абсолютное неумение объяснять, либо завуалированное "я и сам не очень-то понимаю". И, как правило, она ничего не объясняет. В том числе и в данном случае.
Атомарность гарантирует, что транзакция рассматривается как единое, неделимое целое. Все операции внутри транзакции должны выполниться полностью — или не выполниться вовсе. Если какая-либо из операций завершилась неудачно, система откатывает всю транзакцию, исключая частичные изменения данных.
Неверно. Завершение запроса с ошибкой может быть штатным событием внутри транзакции. И уж во всяком случае не означает безусловного прерывания транзакции и отката.
Откат должен выполняться явно. А факт возникновения ошибки в ходе выполнения транзакции просто является маркером, что откат МОЖЕТ потребоваться. Для чего может выполняться даже достаточно значимый анализ того, где возникла ошибка, какая именно и по какой причине. К слову, порой транзакцию требуется откатить и без возникновения ошибок в ходе выполнения её запросов.
Фраза верна лишь для одиночного запроса, который сам по себе является скрытой транзакцией.
Очередной токсичный комментарий с "налетом экспертности". Оба пункта можно интерпретировать по разному, но вы решили все таки докопаться до формулировки и показать какая вы эксперт и знаете что ошибки нужно обрабатывать. Однако если не цепляться к каждому слову вроде вполне очевидно что имелось ввиду( особенно в контексте основной темы статьи). Я вот токсиков не понимаю - вам живётся легче или интереснее если свое "важное" мнение вставите даже если это субъективная оценка?
Автор объясняет суть атомарности и объясняет правильно, вы же просто докапываетесь до мышей или до блох. Разумеется, в транзакции "ошибка" а-ля исключение, может быть перехвачена, а rollback может быть вызван без исключения-ошибки, на основе проверки бизнес-условий. Понятно почему автор не стал останавливаться на таких тривиальностях. Непонятно почему вы преподносите эти тривиальности с таким апломбом.
ACID-свойства транзакций в SQL