Должна ли быть транзакция для чтения запросов?

Ответ 1

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

myRows = query(SELECT * FROM A)
moreRows = query(SELECT * FROM B WHERE a_id IN myRows[id])

Если между двумя запросами кто-то изменяет B, чтобы удалить несколько строк, у вас возникнет проблема.

Ответ 2

Подобно тому, что сказал RoBorg, вы делаете транзакции SELECTS w/i для предотвращения чтения данных phantom между операторами. НО важно отметить, что уровень изоляции транзакций по умолчанию в SQL Server - READ COMMITTED, который предотвратит только грязные чтения; для предотвращения phantom данных вам нужно будет использовать хотя бы ПОВТОРНОЕ ПРОЧИТАНИЕ. Msgstr "Использовать этот параметр только при необходимости."

http://msdn.microsoft.com/en-us/library/ms173763.aspx

Ответ 3

Я обнаружил, что "транзакции" ведут себя по-разному на разных SQL-серверах. В некоторых случаях запуск транзакции блокирует все другие соединения от возможности выполнять любой SQL до тех пор, пока транзакция не будет выполнена или отката (MS SQLServer 6.5). У других нет никаких проблем, и они блокируются только при наличии модификации (оракула). Блокировки могут даже расширяться, чтобы охватить только ваши изменения - блокировки ячеек/блокировки строк/блокировки страниц/блокировки таблиц.

Обычно я использую транзакции только тогда, когда целостность данных между несколькими инструкциями insert/delete/update должна поддерживаться. Даже тем не менее, я предпочитаю реализовать это, используя каскадные удаления с помощью DB, чтобы база данных делала это автоматически и атомарно.

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

Ответ 4

Я проверял это за последние несколько минут, так как это то, о чем я должен знать больше. Вот что я нашел.

Транзакции были бы полезны вокруг выбора, если вы хотите заблокировать эту строку, пока человек читает записи, и не хочет, чтобы он модифицировался или читался. Например, запустите эти запросы:

(в окне запроса 1)

НАЧАТЬ TRAN SELECT * FROM MYTABLE WITH (ROWLOCK XLOCK) ГДЕ ID = 1

(в окне запроса 2)

SELECT * FROM MYTABLE ГДЕ ID = 1

(окно запроса 2 не будет возвращать результаты, пока вы не запустите это в окне 1)

COMMIT TRAN

Полезные ссылки:

http://msdn.microsoft.com/en-us/library/aa213039.aspx

http://msdn.microsoft.com/en-us/library/aa213026.aspx

http://msdn.microsoft.com/en-us/library/ms190345.aspx

Моя цель состояла в том, чтобы что-то блокировать - и, наконец, он работал после добавления XLOCK там. Просто использование ROWLOCK не работало. Я предполагаю, что он выдавал общую блокировку (и данные были прочитаны).. но я все еще изучаю это.

Добавление - WITH (UPDLOCK ROWLOCK) - позволит вам выбрать и заблокировать строки для обновлений, что поможет с concurrency.

Будьте осторожны с подсказками в таблице. Если вы начнете применять их беспорядочно, ваша система будет замедляться при обходе, если вы получите даже небольшое количество пользователей в своем приложении. Это единственное, что я знал, прежде чем смотреть на это:)

Ответ 5

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

Ответ 6

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

Две транзакции:

1. для чтения\выбора.
2. для вставки и фиксации каждой строки X.

позволит вам сделать это правильно, в то время как с одной транзакцией, не разделенной, чтение и запись не позволят вам выполнить фиксацию без потери читателя.