Когда лучше подтверждать транзакции

← →
Тучудище (2005-06-29 15:06) [0]

Решил потихоньку осваивать IBX, в принципе все понятно с загадочным компонентом транзакция разобрался, одно только мне не совсем ясно наткнулся на статью в сети где четко и ясно написано что не стоит подтверждать транзакцию после добавления каждой новой записи(сбило с толку). Ув. мастера подскажите плиз, по какой логике надо действовать чтобы понять, когда ее нужно подтвердить...
Разберем пример обычного справочника
Пользователь добавил несколько запись
Вижу два варианта
1) Автоматическое подтверждение(Если после каждой вставки нельзя то когда)
2) Кнопка подтвердить транзакцию (сами знаете чем это грозит....)

← →
Zacho © (2005-06-29 15:08) [1]

Почитай статьи на http://www.ibase.ru

← →
Zacho © (2005-06-29 15:11) [2]

Тучудище (29.06.05 15:06)
1) Автоматическое подтверждение(Если после каждой вставки нельзя то когда)

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

← →
Тучудище (2005-06-29 15:16) [3]

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

При массовой вопросов нет! Смутило что нежелательно комитить после каждой записи

← →
Zacho © (2005-06-29 15:20) [4]

Тучудище (29.06.05 15:16) [3]

Это действительно самый разумный вариант. Естественно, что модификация данных при этом должна производиться в отдельной транзакции.
Почитай, например, http://www.ibase.ru/devinfo/ibx.htm

Тучудище (29.06.05 15:16) [3]
Смутило что нежелательно комитить после каждой записи
Кому "не желательно" ? В каких случаях ? Случаи разные бывают ...

← →
Anatoly Podgoretsky © (2005-06-29 15:22) [5]

Тучудище (29.06.05 15:16) [3]
Смутило что нежелательно комитить после каждой записи

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

← →
Тучудище (2005-06-29 15:24) [6]

Спасибо за ответы! они наставили меня на пусть истиный

← →
kaif © (2005-06-29 16:01) [7]

При добавлении одиночной записи в справочник имеет смысл подтверждать как раз сразу после добавления.
А вот при создании многострочного документа и особенно при его редактировании иногда удобно так устроить программу, чтобы коммитить или откатывать все изменения, внесенные пользователем в этот документ (вдруг он решит все эти изменения вообще не сохранять). Я обычно на окне "документа" делаю кнопку "сохранить". А при закрытии окна, если были несохраненные изменения, в OnCloseQuery формы спрашиваю примерно так:

procedure TMyForm.FormCloseQuery(Sender: TObject; var CanClose: Boolean);
begin
if ModifiedButton.Enabled then
case MassageDlg("Сохранить изменения в документе таком-то?",
mtConfirmation, [mbYes, mbNo, mbCancel], 0) of
mrYes: SaveChanges;
mrCancel: CanClose := False;
end;
end;

procedure TMyForm.SaveChanges;
begin
with MyDataSet do
if State in [dsEdit,dsInsert] then
Post;
MyDataSet.Transaction.Commit;
ModifiedButton.Enabled := False;
end;

Пользователям это видится логичным.

← →
Desdechado © (2005-06-29 19:37) [8]

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

← →
Anatoly Podgoretsky © (2005-06-29 20:09) [9]

kaif © (29.06.05 16:01) [7]
Так это и есть транзакция в ее прямом толковании а не в компьютерном, единое неделимое действие.

Например при массовом копировании существуют две ситуации, каждая запись не зависима от другой - соответственно транзакция на каждую запись. Второй случай все записи должны быть скопированы полностью, не докопирование одной записи ведет к нарушению целостности - транзакция все записи. Промежуточных вариантов быть не может, это нарущение целостности или неэффективность.
Представим себе для первого случая рекомендацию делать копирование в транзакции по 100000 записей, пускай на записи 99999 произошла какая либо проблема, все предыдущии 99998 пошли насмарку. Получаем не экономию времени (а об транзакционности просто и говорить не призодится все 100000 операций независимы друг от друга), а получаем резкую его потерю, ничем не обоснованную.
Недавно мы устанавливали у себя базу MSSQL, где был импорт из ФоксПро. Весь импорт был атомарен, нельзя было закачать неверную информацию. Благодаря транзакционности мы получили целостную базу, а в процессе импорта были обнаружены несколько недопустимых значений в оригинале.
Без единой транзакции мы бы имели не консистентную систему и долго бы искали где проблема. А так просто методом деления пополам иы проблемы быстро обнаружили и устранили. В новой базе недопустимые значения уже появиться не могут.

← →
msguns © (2005-06-30 09:47) [10]

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

← →
Sergey13 © (2005-06-30 09:57) [11]

2[10] msguns © (30.06.05 09:47)
> лучше всего
Лучше чем что? Насколько лучше? 8-)

← →
msguns © (2005-06-30 10:27) [12]

>Sergey13 © (30.06.05 09:57) [11]

Хочется полялякать ? Я не против ;) Только эта.. давай в Потрепацца ;))

← →
Sergey13 © (2005-06-30 10:33) [13]

>Хочется полялякать ? Я не против ;)
Да не то что бы сильно хочется. Хоть и не против (с приятным человеком приятно полялакать). Я уже догадываюсь, что ты скажешь. А ты наверное догадываешься, что я отвечу. 8-)
Я ведь переспросил просто так. 8-)

>Только эта.. давай в Потрепацца ;))
Можно и туда. 8-)

← →
Игорь Шевченко © (2005-06-30 10:56) [14]

"Hе секрет, что rollback надо делать пореже,
Лучше делать почаще commit!
Я программой своей скоро сервер повешу -
У админа пускай голова поболит.

Под крики о кастрации,
В обкуренной прострации,
Как следствие мутации
Рождается в момент
Rollback segment для маленькой,
Для маленькой такой транзакции,
Для скромной такой транзакции
Огромный такой сегмент!

Hе секрет, что rollback - это язва и грыжа,
Геморрой и чуть-чуть гайморит.
Если ты программист, а не ослик бесстыжий -
Лучше делай почаще commit!

Припев.

Hе секрет, что друзьям тоже надо ресурсы,
Hадо память, процессор и диск...
Так что делай commit, а иначе... ты в курсе,
Что rollback - для тебя неоправданный риск.

Припев. "

← →
msguns © (2005-06-30 11:11) [15]

Супер !!!
Сам придумал ?

← →
Игорь Шевченко © (2005-06-30 11:44) [16]

msguns © (30.06.05 11:11) [15]

Нет конечно. Изначально в fido увидел, потом в инете нашел :)

← →
Val © (2005-06-30 12:00) [17]

кстати, в песенке довольно вредный совет о необходимости частых коммитов в оракле.

← →
Игорь Шевченко © (2005-06-30 12:09) [18]

Val © (30.06.05 12:00) [17]

Кстати да.

← →
Sergey13 © (2005-06-30 12:13) [19]

2[17] Val © (30.06.05 12:00)
Ну, если "частых"="ненужных", то да. Иначе почему вредный?

← →
Digitman © (2005-06-30 12:17) [20]

> Когда лучше подтверждать транзакции

тогда когда нужно подтвердить перевод БД из одного устойчивого состояния в другое

а уж что конкретно входит в "устойчивое состояние" - состояние до/после вставки/модификации/удаления одной ли единственной записи либо вставки/модификации/удаления более чем одной записи в более чем одной таблицах - это определять тебе как разработчику

← →
Игорь Шевченко © (2005-06-30 12:24) [21]

Sergey13 © (30.06.05 12:13) [19]

> Иначе почему вредный?

потому что возможно появление сообщения "Snapshot too old"

← →
Sergey13 © (2005-06-30 12:34) [22]

2[21] Игорь Шевченко © (30.06.05 12:24)
Все таки надо уточнить критерии "частости" и "полезности", ИМХО.
Понятно, что при вставке/апдейте 1000 записей комитить каждую глупо. А если в гриде менять записи, то по твоему надо после каждой комитить или нет? Я думаю, что надо. Это часто?

← →
Игорь Шевченко © (2005-06-30 12:39) [23]

Sergey13 © (30.06.05 12:34) [22]

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

← →
Sergey13 © (2005-06-30 12:42) [24]

2 [23] Игорь Шевченко © (30.06.05 12:39)
>Не стоит оперировать критериями "часто/нечасто"

Так и я к тому веду. Комитить надо по мере необходимости (с учетом технических возможностей разумеется), а не часто/редко.

← →
Игорь Шевченко © (2005-06-30 12:51) [25]

> Комитить надо по мере необходимости (с учетом технических
> возможностей разумеется),

Так об этом и речь, собстна. Необходимость каждый программист может понимать по-разному :)

← →
Val © (2005-06-30 12:59) [26]

>[19] Sergey13 © (30.06.05 12:13)
Естественно речь о ненужных. Потому что, некоторые товарищи, считают, что при вставке большого кол-ва записей, они получат выигрыш в скорости при нескольких подтверждениях, а не одном, после всей вставки. Кстати, об этом неплохо написано у того же Тома Кайта, с примерами, тестами и т.д.

← →
Игорь Шевченко © (2005-06-30 13:06) [27]

Sergey13 © (30.06.05 12:42) [24]

Собственно, кое-что есть здесь

http://www.relcom.ru:8080/scripts/ShowArticle.cgi?g=/relcom/comp/dbms/oracle/&a=8776

А у Кайта действительно неплохо написано.

← →
Desdechado © (2005-06-30 13:18) [28]

хм, а причем тут Оракл?
Транзакция - она и на оракле транзакция.
Другое дело, что в разных СУБД она с разными нюансами реализована. Но тогда см. у автора топика - у него IB, туда и комментируйте.

>Digitman © (30.06.05 12:17) [20]
>а уж что конкретно входит в "устойчивое состояние" - состояние до/после вставки/модификации/удаления одной ли единственной записи либо вставки/модификации/удаления более чем одной записи в более чем одной таблицах - это определять тебе как разработчику

Вообще-то для "групповух" придумали хранимки и триггера.

Я бы ВСЕ операции над данными разделил на 3 большие логические (в плане перевода БД из одного завершенного/целостного состояния в другое) группы:

1. Одиночные. Пример: справочники, заголовки документов, "логовые" таблицы и т.д. Т.е. объектом одного целостного изменения (транзакции) является одна единственная запись одной таблицы.

2. Одиночные связанные. Примеры: сложные справочники, граф-структуры (типа состава изделия), "парные" связки типа классического примера перевода денег с одного счета на другой). Изменение одной записи в таблице должно сопровождаться изменением другой записи в другой или этой же таблице. В контексте одной транзакции делается два (иногда чуть больше) логически связанных изменения в одной или двух таблицах.

3. Групповые (каскадные). Проводка/откат одного или группы сложных документов (типа накладных или лицевых счетов), когда в нескольких (иногда в десятке и даже более) таблицах меняется произвольное кол-во записей. При этом должны быть выполнениы либо ВСЕ измения, либо НИ ОДНОГО.

Во 2, а особенно в 3-м случае апдэйты следует заворачивать в ХП (или в триггера, как кому больше по душе), в то время как в 1-м одиночный запрос вполне "укладывается" в рамки "клиентской" транзакции.

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

Существенное замечание.
Умышленно не затронута проблема кэширования изменений на клиенте, существенно влияющая на "политику" транзакций приложения.

Все - ИМХО ;))

> msguns © (30.06.05 13:27) [30]

> Вообще-то для "групповух" придумали хранимки и триггера

бесспорно.
но никто не напрягает использовать для "групповухи" искл-но серверную сторону, и на суть вопроса это тоже не влияет

msguns © (30.06.05 13:27) [30]

> Во 2, а особенно в 3-м случае апдэйты следует заворачивать
> в ХП (или в триггера, как кому больше по душе), в то время
> как в 1-м одиночный запрос вполне "укладывается" в рамки
> "клиентской" транзакции.

Честно говоря, не понимаю, почему надо заворачивать. Это ж сколько параметров надо передать в процедуру, если планируется изменение множества записей во множестве таблиц ?

Сколько нужно, столько и передавать. А шо, жалко? Зато быстрее

>Игорь Шевченко © (30.06.05 13:32) [32]
>Честно говоря, не понимаю, почему надо заворачивать. Это ж сколько параметров надо передать в процедуру, если планируется изменение множества записей во множестве таблиц ?

"Надо" - это не то слово, которое уместно во всех случаях. Я же написал во-первых, про имхо, а во-вторых, про искусство ;))

По поводу параметров..
Если делается откат документа (а это проводит к изменению в 3,4, а иногда десятке таблиц), то параметром служит только его ID, если же откатывается группа документов (как пример, откат всех документов, начиная хронологически с указанного, при правке прихода в некоторых складских системах с учетом по поставкам (партионный учет)), то там параметром служит лишь дата-время. Всего лишь.. Обо всем остальном "знает" сама ХП.

msguns © (30.06.05 13:59) [34]

Вах. Я не знаю понятия "приход в складских системах" в теории баз данных. Давай о терминологии договоримся.

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

>Игорь Шевченко © (30.06.05 14:23) [35]
>Вах. Я не знаю понятия "приход в складских системах" в теории баз данных. Давай о терминологии договоримся.

Складские системы приведены как пример. Не нравится склад, возьми расчет з/пл для подразделения. Или расчет угла атаки для аивиапушки. Какая разница-то ?

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

Передать в процедуру ID удаляемого документа или TDataTime стартового в группе проблема ?
Теперь я не понял ;(

msguns © (30.06.05 14:41) [36]

>
> Передать в процедуру ID удаляемого документа или TDataTime
> стартового в группе проблема ?

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

>Игорь Шевченко © (30.06.05 14:52) [37]
>Я наверное тебя не так понял. Я думал, ты имеешь в виду, что вставка данных для такой транзакции тоже должна быть обернута в процедуру. А удалить проблем нету, обычно в триггере.

Откатить - это вовсе не удалить ! В триггер нельзя, ибо если документ непроведенный, то любое его изменение НЕ приводит к изменению, например, текущих остатков. А если проведенный, то приводит. Но это так, к слову.

2 msguns © & Игорь Шевченко ©
Похоже вы про разные откаты спорите. Один про откат документа другой про откат транзакции. Нет?
ЗЫ: Есть и еще значения у отката. 8-)

msguns © (30.06.05 15:26) [38]

> если документ непроведенный, то любое его изменение НЕ приводит
> к изменению, например, текущих остатков. А если проведенный,
> то приводит. Но это так, к слову.

А давай я тебе про сэмплинг или про клиринговые методы взаимозачетов или про BSP с ARC чего-нибудь расскажу интересное и познавательное ?
Развелось бухгалтеров, понимаешь, плюнуть негде :)

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

Когда лучше подтверждать транзакции Найти похожие ветки