МСУhVostt, что ты там бурлишь себе под нос, транзактщионщик? Иди паси коз, и не забудь их оттестировать

МСУ ты в своём репертуаре: пук-пук-пук в лужу. И сел в лужу. Ведь ты единственный в мире знаешь, как работать с БД без транзакций

Алексей КПро лишние блокировки, в том числе повышающие вероятность мёртвой блокировки, выше уже написали.

Наблюдал случай, один админ самовольно решил почистить таблицу с логами. Откуда ему было знать, что MSSQL выполняет команду delete from Log where EntryDate < @d в одной транзакции. Он сначала пару часов ждал, пока оно удалится. Потом ему надоело ждать, он отменил запрос. Потом все столько же ждали, пока отменится транзакция. На всё ушло часов ~6.

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

А как выкрутились из ситуации? Забили на чистку логов?

МСУА я разве без них обхожусь?

Ты только недавно говорил «АПРИОРИ ОПАСНА И ВРЕДНА», скажи, ты не осёл случайно? Упёртое тупое животное. Сам сказал «опасна и вредна» и тут же даёшь заднюю.

МСУ,

И ещё скажи мне, как вот это твоё высказывание:

МСУпредставь себе ситуацию, когда ночной джоб перелопатил 29.9К сотрудников и по каким-то причинам упал

Согласуется с твоими ссылками про проблемы в многопользовательской среде, ведь как бы «ночной джоб» работает обычно с БД в одно рыло, монопольно?

Я всё жду не дождусь от тебя реальный проблемный кейс.

Shocker.ProhVosttА как выкрутились из ситуации? Забили на чистку логов?очевидно, операции, затрагивающие такие большие объемы просто делаются в цикле частями. Тут целостность транзакции не нужна. Мало того, суммарно на это уйдет в разы меньше времени, так как СУБД не потребуется делать не*$*ически огромную запись в лог транзакций, а потом ее коммитить.

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

Интересны примеры с бизнес-данными. Когда же это действительно вредно.

МСУТы реально дурак? Выдрал фразу из контекста и прикинулся идиотом?

МСУПлюс, на реальных массивах данных транзакционность априори вредна и опасна. Это ж тебе не пару тыщ строк обновить.

Разницу видишь между "транзакционность вредна" и "транзакционность вредна больших выборках"? Убей уже себя, глупый

Реальные массивы данные === большие выборки? Ты случаем, не таджик?

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

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

МСУhVosttЯ всё жду не дождусь от тебя реальный проблемный кейс.
Ты дурак? :) Нет, честно ответь, ты идиот?

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

Алексей КНе нужно баловаться с избыточностями, тогда бороться за целостность транзакциями не придётся. :-)

Т.е. всё зависит от требований, задач и ситуации. «Транзакции = плохо» такое же нелепое утверждение, как и «Транзакция = хорошо».

Какие-то абстрактные «реальные массивы данных» о которых с упорством глупого прыщавого юнца вещает МСУ, для которых злые транзакции «априори опасна и вредна», это ровным счётом ни о чём.

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

Есть реальный пример, где такая ситуация недопустима в принципе — банковская система. Но почему только там ошибки не допускаются, а где-то ещё могут допускаться, особенно в рамках крупной организации. Что это за глупость такая, типа часть сотрудников «не загрузилась»? Это что вообще? Это не нормально. Либо всё, либо ничего, если сама задача не подразумевает иное (когда на первом месте стоит задача хоть что-то обработать, не обращая внимания на ошибки).

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

Алексей КВторой случай: сущность хранится в нескольких таблицах. Больше случаев не припомню.

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

Алексей КЭтого никто не говорил. Говорили, что транзакции нужно делать как можно короче. МСУ даже МСДН цитировал. :-)

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