|
|
|
|
#1 |
|
Участник
|
Если предположить, что за раз будет удаляться не очень много записей - в пределах 10 тысяч, допустим (иначе транзакционный лог раздуется, и транзакция удаления записей будет достаточно долго отрабатывать) - то можно использовать такой подход: создать Query для выбора RecId удаляемых записей, при этом записи фильтровать по произвольным параметризируемым критериям, затем полученные RecId записать во вспомогательную таблицу (по аналогии с тем, как работает класс RecordReferenceList_RU) и в delete_from приджойнить ее к таблице, записи из которой удаляются.
|
|
|
|
| За это сообщение автора поблагодарили: Мартынов Дмитрий (1). | |
|
|
#2 |
|
Участник
|
Не совсем так.
ты говоришь об ОДНОМ клиенте. А Аксапта - сетевая система. Обрати внимание на вложенную транзакцию, которая присутствует в предлагаемом тебе примере. В цикле с маленькими транзакциями блокировки не эскалируются. Время, на которое блокируется каждая запись минимально. delete_from будет делаться в одной транзакции. Следовательно велика вероятность эскалации блокировок. Кроме того, все затрагиваемые записи будут заблокированы до окончания транакции. Следовательно общая производительность скорее всего будет ниже из-за блокировок, а вероятность deadlock'ов сильно возрастает. =============== Где-то в книжках по аксапте читал, что когда вводили групповые операции delete_from, updaterecordset и insertrecordset крепко думали об этом. Суть - в операторах за быстродействие полностью отвечает программист. И это его непосредственная задача думать о производительности. Query, в отличие от оператора, может корректироваться пользователем. Поэтому, христос его знает, что может ввести туда пользователь... и условия по полям без индекса, и дополнительные join... поэтому вводить такую фичу в Query не стали. |
|
|
|
| За это сообщение автора поблагодарили: Мартынов Дмитрий (1). | |
|
|
| Опции темы | Поиск в этой теме |
| Опции просмотра | |
|