Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Когда лучше подтверждать транзакции [D5, IB6.x]

Страницы: < 1 2 3 >
Тучудище © (2005-06-29 15:06:00)
Решил потихоньку осваивать IBX, в принципе все понятно с загадочным компонентом транзакция разобрался, одно только мне не совсем ясно наткнулся на статью в сети где четко и ясно написано что не стоит подтверждать транзакцию после добавления каждой новой записи(сбило с толку). Ув. мастера подскажите плиз, по какой логике надо действовать чтобы понять, когда ее нужно подтвердить...
Разберем пример обычного справочника
Пользователь добавил несколько запись
Вижу два варианта
1) Автоматическое подтверждение(Если после каждой вставки нельзя то когда)
2) Кнопка подтвердить транзакцию (сами знаете чем это грозит....)

Игорь Шевченко (2005-06-30 14:52:00) [21]
msguns © (30.06.05 14:41) [36]

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

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

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

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

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

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

Игорь Шевченко (2005-06-30 14:23:00) [23]
msguns © (30.06.05 13:59) [34]

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

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

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

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

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

Андрей Жук (2005-06-30 13:48:00) [25]
Сколько нужно, столько и передавать. А шо, жалко? Зато быстрее

Игорь Шевченко (2005-06-30 13:32:00) [26]
msguns © (30.06.05 13:27) [30]

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

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

Digitman (2005-06-30 13:31:00) [27]

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

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

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

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

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

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

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

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

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

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

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

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

Все - ИМХО ;))

Val (2005-06-30 13:21:00) [29]
> [28] Desdechado © (30.06.05 13:18)
при песенке :)
ему уже накомментировали. теперь просто разболтались.

Desdechado (2005-06-30 13:18:00) [30]
хм, а причем тут Оракл?
Транзакция - она и на оракле транзакция.
Другое дело, что в разных СУБД она с разными нюансами реализована. Но тогда см. у автора топика - у него IB, туда и комментируйте.

Игорь Шевченко (2005-06-30 13:06:00) [31]
Sergey13 © (30.06.05 12:42) [24]

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

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

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

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

Игорь Шевченко (2005-06-30 12:51:00) [33]

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

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

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

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

Игорь Шевченко (2005-06-30 12:39:00) [35]
Sergey13 © (30.06.05 12:34) [22]

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

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

Игорь Шевченко (2005-06-30 12:24:00) [37]
Sergey13 © (30.06.05 12:13) [19]

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

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

Digitman (2005-06-30 12:17:00) [38]

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

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

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

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

Игорь Шевченко (2005-06-30 12:09:00) [40]
Val © (30.06.05 12:00) [17]

Кстати да.

Страницы: < 1 2 3 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »