Что делает транзакцию вокруг отдельного оператора, делают?
Я просто хотел подчеркнуть тонкий точка . Конструкция переключателя создает целый, объем гражданина первого класса. Таким образом, возможно объявить (и инициализировать) переменная в операторе переключения перед первой маркировкой случая, без дополнительная пара скобки:
switch (val) {
/* This *will* work, even in C89 */
int newVal = 42;
case VAL:
newVal = 1984;
break;
case ANOTHER_VAL:
newVal = 2001;
break;
}
4 ответа
Ничего не делает. Все отдельные операторы SQL (за редкими исключениями, такими как массовая вставка без журнала или таблица усечения) автоматически «в транзакции», независимо от того, говорите вы это явно или нет .. (даже если они вставляют, обновляют или удаляют миллионы строк) .
РЕДАКТИРОВАТЬ: на основе комментария @ Phillip ниже ... В текущих версиях SQL Server даже массовая вставка и таблица усечения записывают некоторые данные в журнал транзакций, хотя и не так много, как другие операции. . Критическое различие с точки зрения транзакций состоит в том, что в этих других типах операций данные в изменяемых таблицах базы данных не находятся в журнале в состоянии, которое позволяет их откат.
Все это означает, что изменения, которые оператор вносит в данные в базе данных, регистрируются в журнале транзакций, чтобы их можно было отменить в случае сбоя операции.
Единственная функция, которая выполняет «Начать транзакцию», «Фиксировать» Команды Transaction "и" RollBack Transaction "позволяют вам поместить два или более отдельных SQL-операторов в одну транзакцию.
EDIT: (для усиления комментариев, помеченных ...) ДА, это можно отнести к" суеверному " программирования, или это может быть признаком фундаментального непонимания природы транзакций базы данных. Более снисходительная интерпретация состоит в том, что это просто результат чрезмерного применения последовательности, что неуместно, и еще один пример эвфемизма Emersons, который: обожаемый маленькими государственными деятелями, философами и богословами
Как сказал Чарльз Бретана, «ничего не делает» - ничего кроме того, что уже сделано.
Когда-либо слышали о «КИСЛОТЕ» требования реляционной базы данных? Эта буква «A» означает атомарный, что означает, что либо оператор работает полностью, либо нет - и пока оператор выполняется, нет другие запросы не могут быть выполнены для данных, затронутых этим запросом. BEGIN TRANSACTION / COMMIT «расширяет» эту функцию блокировки на работу, выполняемую несколькими операторами, но ничего не добавляет к отдельным операторам.
Однако журнал транзакций базы данных всегда записывается, когда база данных изменена (вставка, обновление, удаление). Это не вариант, факт, который имеет тенденцию раздражать людей. Да, есть странности с массовыми вставками и режимами восстановления, но они все еще записываются.
Я также укажу уровни изоляции. Возня с этим повлияет на отдельные команды, но это все равно не приведет к тому, что запрос, завернутый в объявленную транзакцию, будет работать иначе, чем "автономный" запрос.
Одно из возможных оправданий состоит в том, что этот единственный оператор может вызвать запуск множества других SQL через триггеры, и что они защищают от чего-то плохого. там, хотя я бы ожидал, что любая СУБД будет иметь здравый смысл для использования неявных транзакций таким же образом.
Еще я могу придумать, что некоторые API-интерфейсы позволяют отключать автоматическую фиксацию, и код написан просто на случай, если кто-то это сделает.
Когда вы запускаете явную транзакцию и выдаете DML , ресурсы, заблокированные оператором, остаются заблокированными, и результаты оператора не видны извне транзакции, пока вы вручную не зафиксируете или не откатите ее.
Это то, что вам может понадобиться, а может и не понадобиться.
Например, вы можете захотеть показать предварительные результаты внешнему миру, сохраняя при этом их блокировку.
В этом случае вы запускаете другую транзакцию, которая помещает запрос блокировки перед фиксацией первого, что позволяет избежать состояния гонки
Неявные транзакции фиксируются или откатываются сразу после завершения или сбоя оператора DML .