Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
Отличная статья! Эх, увидеть бы ее 2 года назад)
(1) YPermitin, так та статья на которую я ссылаюсь наверно года 3 года назад и вышла 🙂
Спасибо за статью!! Очень познавательно для меня.
Еще хотел уточнить один момент для себя. Насколько я понимаю даже если бы мы накладывали для регистра ОстаткиТоваров блокировку через объект «БлокировкаДанных», то всерано пришлось бы использовать «БлокироватьДляИзменения» т.к. для регистра включено разделение итогов ?
Спасибо.
(3) headMade, А какая тут связь?
(0) Павел, а подскажите, пожалуйста, еще такую вещь:
Не правильнее ли будет для контроля остатков получать данные не из табличной части документа, а уже из таблицы регистра? Я вижу несколько причин обращаться сразу к регистру:
1. В табличной части не готовые данные — требуется как минимум пересчитать количество из единиц в документе в единицы хранения остатков
2. Это более универсально — по одному регистру движения формируются разными документами, у которых названия табличных частей, реквизитов и т.д. могут быть разными, а если брать данные из регистра, то текст запроса будет одинаков для всех документов
Не думаю, что по скорости чтения данных из регистра будут какие-то проблемы, ведь регистратор, по которому устанавливается отбор для чтения данных, всегда входит в индекс регистра.
Если я ерунду говорю, сильно не пинайте, лучше объясните, в чем я не прав 🙂
Спасибо
(5) hulio, прошу прощения, но вообще не понял вопроса.
|ВЫБРАТЬ
| Остатки.Товар.Представление КАК ТоварПредставление,
| Остатки.КоличествоОстаток
|ИЗ
| РегистрНакопления.ОстаткиТоваров.Остатки(
Мы берем данные из регистра. Все остальное, для оптимизации расчета временной таблицы.
Во втором запросе без данных ТЧ документа не обойтись.
(2) в то время не попалась на глаза)
(6) хотел сказать, что первый запрос (который для контроля остатков) можно было бы переписать таким образом:
Показать
(8) hulio, ага, понял. Можно. Я традиционно делал.
(9) про «традиционно» я понял 🙂 Мне интересно ваше мнение, можно ли писать так, как предложил я? Просто я пока вижу только преимущества, но может есть и недостатки, которые их нивелируют?
(10) hulio, чаще всего на основании данных ТЧ документа требуется сделать движения не по одному регистру. Да и сворачивать строки ТЧ документа при формировании движений будет не лишним. Вывод: то что Вы предлагаете, в конкретном частном случае можно использовать, и это удобно, но в общем случае, я думаю, будет довольно мало ситуаций, когда можно было бы применить подобную методику.
(8) какая то бредятина написана..
Проводим первый раз документ — в регистре ОстаткиТоваров ничего нет при условии
ГДЕ
| Док.Регистратор = &Ссылка
не запрос, а мусор.
(12) Ёпрст, сам ты мусор )))
Перед выполнением запроса вообще-то запись движений происходит 😉
(11) да, что-то не учел, что данных в одном регистре может быть недостаточно для проведения по другому регистру 🙂
Тем не менее, считаю, что в угоду универсальности кода можно использовать чтение данных из регистра, а не из ТЧ.
Как правило регистров, по которым нужен контроль остатков не много, а документов, формирующих движения по ним — достаточно большое количество. Поэтому для каждого документа прописывать контроль муторно (надо учитывать, например, что у них может быть разный состав табличных частей и реквизитов), а так можно для контроля по конкретному регистру создать универсальную процедуру для любых видов регистраторов.
Само собой, что это может сказываться на производительности при большом количестве контролируемых регистров и серьезном документообороте, но думаю, такой подход имеет право на существование.
(13) че-то про запись движения до того как не подумал.
(14) hulio, ничего против комментария не имею, но замечу, что при формировании движений в регистры их имеет смысл оптимизировать (отбросить незначащие, свернуть ТЧ и пр). И в общем случае получится, что запрос к ТЧ документа в любом случае будет построен. А если уже есть выборка из ТЧ, то смысл обращаться к другой таблице пропадает. Это в общем случае… Это я по поводу универсальности…
всё равно, без запроса к тч не обойтись, особенно в типовых.
Если только всё не переписывать.
Там повсеместно есть конструкции типа подготовитьтаблицу документа и т.д..
Спасибо, полезно! В коде не увидел ОсталосьСписать = ОсталосьСписать — Списать;
GROOVY, большое спасибо за статью, очень интересно. Но у меня пара вопросов, если можно.
1) А разве не нужно при оперативном проведении получать актуальные итоги, а не на момент времени? Как вообще работает этот процесс получения актуальных итогов? Обязательно ли их получать на пустую дату?
2) Вопрос немного не в тему, но может быть подскажете. По экзамену специалист на платформу. Решенная вами задача почти копия задачи 1.1 из сборника. Так вот, решить задачу можно и используя старую методику проведения, на одном регистре. Как всё таки правильно делать на экзамене? Использовать 2 регистра и новую методику, или 1 регистр и старую? Я спрашивал на вашем форуме, там предпочитают 1 регистр.
Спасибо 🙂
(18) Tsaregorodtsev, спасибо, поправил.
(19) slazzy, 1. А кто такое сказал? 2. Снизят балл.
(20)
1) так я сам испрашиваю. Просто неоднократно видел вот такую конструкцию.
МоментВремени = ?(Режим = РежимПроведенияДокумента.Неоперативный, МоментВремени(), ‘00010101’));
И это казалось логичным 🙂 вы же в данном случае не использовали данную конструкцию, вот я и уточнил а нужна ли она.
2) То есть при партионном учете, на экзамене специалист, требуется делать именно так, как в вашей статье? Просто, на самом деле, смотрел десятки решенных билетов от разных людей и они все делали на одном регистре. Хотя мне вариант на двух тоже кажется более правильным.
Мир этому дому!
Спасибо за интересный материал.
(21) slazzy, По первому пункту, думаю, что правильнее будет уточнить у автора кода, какую цель он преследовал. По второму пункту я уже ответил — снизят балл.
>> раньше мы могли принудительно записать движения документа (наборы данных),
>> но при окончании транзакции проведения наборы данных записывались еще раз
Это точная информация? У документа два свойства: «Записывать выбранные» и «Записывать модифицированные». Если мы один раз принудительно записали набор движений, то свойство модифицированности у него пропадет и при окончании обработки проведения повторной записи не будет.
Сейчас уже не могу ручаться на 100%, но помню что проверял этот момент и повторной записи не происходило. Связал тогда это с тем, что свойство «Модифицированность» у уже записанных движений = Ложь.
По этому как минимум один плюс новой схемы можно вычеркнуть.
(24) BH, контролировать запись/не запись мы могли? Нет. Про старую запись при окончании проведения Вы правы, однако признак модификации набора записей мы ни снять ни установить не можем.
Мир этому дому))) Спасибо за интересный материал))))
Кстати, хотелось бы еще раз отметить важное свойство записи с установленным флагом БлокироватьДляИзменения, которое многие упускают из виду. При записи блокируются записи не только по тем измерениям, которые содержатся в записываемом наборе, но блокировка происходить и по тем записям, которые уже есть в базе по указанному в наборе записей отбору. Это не зависит от того, есть в записываемом наборе записи или нет.
В статье это отмечено, но несколько в другом контексте, при записи пустого набора записей
Извиняюсь за дублирование информации, но не раз на форумах встречал вопросы связанные с этим и именно этот момент ставил вызывал у людей затруднение и это кажется важным.
(27) BH, да это многие упускают из виду.
(25)
Это так, однако после выполнения
для каждого набора записей из этой коллекции Модифицированность() = Ложь.
Таким образом по окончании обработки проведения если мы записали движения вручную и у документа установлено свойство «Записывать модифицированные» запись произведена не будет.
Хотел написать, что повторная запись произведена не будет.
(21) slazzy,
Лучше написать так:
Просто неоднократно видел вот такую конструкцию.
МоментВремени = ?(Режим = РежимПроведенияДокумента.Неоперативный, МоментВремени(), Неопределено));
Хотя не проверял, возможно эти выражения равнозначны.
Здесь такой момент. Установка параметров виртуальных таблиц в Неопределено равносильна тому, что мы его не указываем. Это, если можно так выразится по отношению к параметрам виртуальных таблиц, параметр по умолчанию. В этом случае в случае оперативного проведения вычисляются итоги на последнюю возможную дату…. с годом 3999 и указанным в справке днем и месяцем 🙂
Какие преимущества это дает? В случае если мы всегда будем указывать МоментВремени() , то в любом случае система будет вычислять остатки на этот момент времени. Хотя возможно есть какой-то аналог точки актуальности и если МоментВремени() оказывается больше нее то это равнозначно тому что параметр не указывается. Но я во всяком случае нигде не встречал такой информации.
Сам всегда предпочитаю писать
МоментВремени = ?(Режим = РежимПроведенияДокумента.Неоперативный, МоментВремени(), Неопределено));
Это простое выражение и гарантированно дает нужный результат.
И конечно же хочется сказать спасибо автору. Пожалуй лучшая статья на эту тему. Понравилось как описано последовательное проведение по оперативному и неоперативному регистрам. Обычно такой связки не приводят, а дают два разных варианта, отдельно по старой методике и отдельно по новой.
(31) BH, я знаю что это означает и для чего пишется ) спасибо. Неопределено можно писать, но виртуальная таблица там ожидает увидеть всё таки дату. Поэтому можно(и как мне кажется правильнее) передавать пустую дату, хотя это и правда не имеет значения.
Я собственно и спросил, почему GROOVY не использовал такую возможность.
Ведь по логике, при оперативном проведении мы записываем пустой набор и мы вполне можем получать остатки из таблицы актуальных итогов, а не на момент времени. Так указывалось много где, к примеру
Я не эксперт и возможно есть какая-то причина ) именно поэтому и интересуюсь
К примеру в этой статье , да и вообще много где.
После длительного изучения темы управляемых блокировок я для себя сделал следующие выводы как «правильно»:
0) Используем 1С 8.3 — база MS SQL в режиме версионника (это важно), а не блокировщика. Для других СУБД вроде как и в 8.2 используется версионирование, но на практике ничего не могу сказать по ним — не пробовал.
1) Движения автоматически не удаляем при перепроведении (иначе сразу в начале проведения получим блокировку).
2) Движения явно в коде не пишем — записываются автоматически системой при записи самого документа (иначе получим деадлоки из-за разного порядка записи в регистры).
3) В регистрах накопления и бухгалтерии убираем возможность разделения итогов (иначе получим конфликт разделяемой и неразделяемой блокировки при контроле остатка).
4) Блокировки явно в коде не устанавливаем (устанавливаются платформой автоматически при записи движений в регистры).
5) Контроль остатков делаем после записи движений регистров (ну собственно «новая» методика :-)).
Почему именно так нужно объяснять подробнее по каждому пункту, но таким образом исключаются деадлоки на уровне СУБД и минимизируется время блокировки на уровне сервера приложений только на время записи движений в регистры.
Такой подход реально работает! Параллельность работы максимально возможная!
P.S.: Хуже всего конечно с регистром бухгалтерии т.к. там плохо разделяются блокировки, но это компенсируется тем что блокировка накладывается только на время записи в регистр, а не на все время проведения документа.
(34) На тему «версионника» можно тут почитать
Еще важное замечание по поводу управляемых блокировок и MS SQL — перевод базы с автоматических на управляемые блокировки существенно улучшает параллельность работы, но если MS SQL работает в режиме блокировщика, остается изрядная «ложка дегтя» в виде того что MS SQL накладывает блокировки по своему усмотрению, что часто приводит к деадлокам на уровне MS SQL и существенной потере параллельности работы. Поэтому только версионник и так как я написал выше. Разработчики 1С много чего понаделали и понаписали на тему управляемых блокировок, но почему то так и не объяснили как выглядит «золотой грааль» 🙂
(34) ZLENKO.PRO, в настоящий момент в реальной эксплуатации юзать 8.3 будет только не очень далекий человек.
(38) А кто говорил о реальной эксплуатации ? Вы ведь тоже про 8.3 написали в своей статье 🙂
«Интересную фишку, раньше мы могли принудительно записать движения документа (наборы данных), но при окончании транзакции проведения наборы данных записывались еще раз. Теперь мы вольны в выборе, что и когда нужно записывать. Маркер записи автоматически снимается при записи набора, тем самым, при окончании транзакции проведения, набор записей еще раз записываться не будет. К чему это приведет? Правильно, к уменьшению блокировок таблиц и к сокращению времени транзакций при проведении.»
Правильным подходом является отсутствие явной записи регистров для исключения взаимоблокировки регистров при разном порядке записи. Правильно ?
(37) На 8.2 такой подход тоже работает, но перевод базы MS SQL в режим версионника нарушает… сами знаете что 🙂 А вот в случае базы на постгри или оракле должно работать и на 8.2
(38) ZLENKO.PRO, я не говорил про 8.3, я только уточнил на какой платформе я делал демопример.
(39) ZLENKO.PRO, правильно…
Одна из «проблем» повышения параллельности работы заключается в том что наложенная (явно в коде или автоматически самой системой) блокировка в процессе проведения документа сохраняется до окончания транзакции, т.е. до конца проведения документа. Поэтому наложение блокировок необходимо максимально отсрочить до самого конца проведения — система сама запишет движения регистров и сама наложит необходимые блокировки.
(42) ZLENKO.PRO, в частном случае, можно писать данные и не в транзакции проведения.
(41) Все что я написал в (34) актуально и для 8.2, однако используя базу MS SQL на 8.2 несмотря на все ухищрения будут появляться ошибки ожидания на блокировках на уровне СУБД 🙁 (хотя «по мнению» сервера приложений их быть не должно :-))
Это не повод не пользоваться тем подходом который я описал, но идеала по параллельности работы таким образом для MS SQL не достигнем 🙁
(44) Пожалуй «отложенное проведение», характерное для некоторых западных систем, отделенное от записи самого документа, является правильным вектором движения и для 1С. Надеюсь что в будущем в типовых конфигурациях так и будет реализовано. Пока приходится работать с тем что есть — я не готов переписать полностью проведение документов даже в УТ, не говоря уже про УПП.
(37) ну к примеру мы уже как год предоставляем сервисы на 8.3…
Павел, могу сказать Вам как практик, теория это конечно хорошо, но версионник скуля обесценивает эту методику.
Более того, я сам преподавал, и очень хорошо помню как время от времени во всех курсах меняется «политика партии». Делайте так… А почему — а потому что так «методически верно»…
Проходит некоторое время, и на тех же курсах ТАК КАК РАНЬШЕ ДЕЛАТЬ НЕ ПРАВИЛЬНО, теперь политика партии ТАКАЯ…
И так по кругу…
короче, конечно методически верно делать как написал Павел 🙂
(4)
Включение режима разделения итогов фактически добавляет в таблицу итогов регистра еще одно измерение, позволяющее распараллелить обновление записей итогов. Свойство БлокироватьДляИзменения этот механизм отключает.
(48) Gilev.Vyacheslav,
объясните почему «версионник скуля обесценивает эту методику» ???
Пожалуйста…
(50) headMade, это бред. Причем в УЦ1 Гончаров его массово продвигает.
(51) headMade, потому что прочитать версию в режиме версионника не вызвает взаимоблокировку, каждый читает свою версию, а если версия «устареет», то вылезет ошибка, не вызывающая взаимное блокирование
получилось ли у меня ответить на вопрос?
прочитал статью, был на курсах в том числе и УЦ 1, конечно понимаю зачем так делать по новой методике, но всеравно пишу решение по старому… незнаю, какие то через чур сомнительные приимущества… кто вообще замерял какую это эффективность на реальной базе между старой и новой методикой… ну скажем на 100 юзерах, сильно заметно ?
Думаю еще методики поменяются, когда платформа к примеру научится «секционировать» данные, и они поделятся на нечто вроде «оперативные» и «архивные»…
(54) AllexSoft, что значит сомнительные — берете инструмент вроде ЦУПа и смотрите статистику, гадать не надо
(56) Gilev.Vyacheslav, у меня нет такой возможности (маленький город), у вас наверняка есть опыт конкретного сравнения, поделитесь ?
пс: сомнительные для меня, стоит ли заморачиваться если пользователей работает не более 15 ? я думаю нет.. у них даже транзакционных блокировок не возникает даже на автоматическом режиме + файловая бд )
(53) Gilev.Vyacheslav,
да, спасибо
(57) AllexSoft, если проблемы нет у вас, это не означает что ее в природе нет
когда вернетесь к проблеме, соберите статистику например бесплатным и будет понятно (оно/не оно) 🙂
(59) Gilev.Vyacheslav, я понимаю что вообще она есть, поэтому и попросил поделиться опытом у кого он есть, у кого возникали подобные проблемы, насколько перевод своих решений с старой методики на новую повлияло на проблему
ps: за ссылку спасибо, пригодится
(52)GROOVY, а заявление что «это бред» чем-то подкрепляется?
Все же кажется правдоподобным что
//3
Движения.Записать();
Блокирует до конца транзакции без «Движения.ОстаткиТоваров.БлокироватьДляИзменения = Истина» только по разделителю итогов а т.к. чтение выполняется без разделителя то для исключения взаимоблокировки и добавляют «Движения.ОстаткиТоваров.БлокироватьДляИзменения = Истина» но только если ВКЛЮЧЕН разделитель итогов это и имеет смысл. Иначе же если разделитель итогов ВЫКЛЮЧЕН — сама запись в регистр накладывает исключительную блокировку до конца транзакции.
Также здесь
Если «и то и другое» то важно проверить настройки объектов. Помните, что вид транзакции наследуется всеми вложенными транзакциями. То есть если документ записывается в автоматической транзакции, а движения делает по регистрам с управляемой… То система немного расстроится и вывалится с ошибкой.
кажется все наоборот. Если существующая транзакция автоматическая то начинаемая тоже. А вот если сначала управляемая а потом автоматическая — ошибка.
(61) rozer, Про бред, было на «Свойство БлокироватьДляИзменения этот механизм отключает.».
«Иначе же если разделитель итогов ВЫКЛЮЧЕН — сама запись в регистр накладывает исключительную блокировку до конца транзакции. » об этом было указано в статье.
Если разделение итогов не будет включено и в режиме пользователя, то в большей части случаев блокировка будет наложена на весь регистр с его таблицами.
Здесь? Т.е. если разделителя нет то несмотря на управляемые режим блочиться весь регистр???
«Свойство БлокироватьДляИзменения этот механизм отключает.»
Не ну момент проведения отключает конечно 🙂
(63) к (62)
(53) Gilev.Vyacheslav, на уровне СУБД чтение версии конечно не вызовет взаимоблокировки, однако взаимоблокировка должна возникнуть на уровне сервера приложений, т.к. блокировка накладывается сервером приложений и сохраняется до конца транзакции (проведений). Я правильно понимаю ?
(62) я думаю вместо тех сложных и запутанных объяснений которые исходят от 1С, надо объяснять проще.
По «новой методике» можно включать разделение у оборотных регистров накопления и отключать его у регистров накопления остатков (по которым делаем контроль остатков после записи). И при таком подходе вообще не нужно думать про «БлокироватьДляИзменения». Потому что получается бред — сначала мы разрещаем разделение, а потом программно через БлокироватьДляИзменения его по сути запрещаем. Ну и в чем тут глубокий смысл ?
(54) AllexSoft, смотря какие пользователи, какая база и какая конфигурация. У меня на 100 пользователях с УПП с базой за 4 года было сильно заметно разницу.
(60) AllexSoft, я в (34) описал вкратце свой опыт (упоминание про 8.3 чисто теоретическое — она на тот момент еще бетой была). Насколько помогло: в УПП в любое время можно запускать проведение по партиям (при том что документы сами проводятся по партиям) не мешая никому работать. Можно запустить 3-4 потока перепроведения документов и они будут идти параллельно без таймаутов. Вот такая разница.
Ну а новую методику контроля остатка я применяю с 2007 года, когда еще 1С говорила что это в корне неверный подход 🙂
(61) rozer, вот объясните мне в чем смысл сначала разрешать разделение итогов, а затем накладывать блокировку, которая по сути запрещает его использовать ? Разработчики из 1С ответят что мы мол сделали функционал, а уж вы думайте пользоваться ним или нет 🙂 Ну а с практической точки зрения ? Как я уже писал я отказался от разделения итогов в принципе. В реальных ситуациях я думаю выигрыш от разделения незначительный. Я больше думал об уменьшении времени транзакционных блокировок.
(65) ZLENKO.PRO, не правильно
но если уж совсем честно подходит к этому вопросу, вызвать взаимную блокировку могут все перечисленные методики, включая последнюю, но вероятность их существенно ниже чем в исходной методике
обсуждается методика в контексте MS SQL Server прежде всего
(70) Gilev.Vyacheslav, Что именно неправильно ?
(71) IvanAlekseev, Файловый вариант в данном контексте не представляет интереса.
Файловый вариант вообще, ни в каком контексте интереса не представляет.
(54) AllexSoft, кстати по поводу 100 человек… Понятно что количество человек весьма условно — даже два человека могут запустить обработку перепроведения документов и начать получать блокировки. Понятно что без блокировок тоже обойтись невозможно. Необходимо повышать параллельность работы пользователей настолько, насколько это возможно и при этом помнить что вероятность возникновения и время ожидания на блокировке прямо пропорционально времени блокировки, а поскольку при проведении блокировки в транзакции, то надо уменьшать время от начала блокировки до конца транзакции. Вот основная отправная точка, а все остальное это уже методы достижения цели.
P.S.: Основная проблема масштабируемости 1С — длинные транзакции при проведении. Думаю что многим это и так понятно, но по опыту многие это не до конца понимают. Решать эту проблему можно по разному, но чаще всего приходится ее решать в уже существующих в том числе типовых конфигурациях и в связи с этим количество способов решения сильно сокращается (в некоторых случаях до нуля :-)).
(69) разделение итогов на порядок повышает производительность записи а остальное-читайте внимательнее пост.
(77) Разделение итогов снижает производительность, т.к. при расчете итогов обрабатывается больше записей 🙂
А по поводу записи, теоретически можно писать параллельно в оборотные регистры накопления, а вот в регистры остатков при «новой» методике контроля остатков параллельно писать нельзя, поэтому и придумали «БлокироватьДляИзменения». Если почитаете форум разработчиков 1С, то там это достаточно подробно расписано. Т.е. фактически для тех регистров, по которым остатки проверяются после записи проще отключить возможность разделения итогов чтобы не заморачиваться с «БлокироватьДляИзменения». С другой стороны запись в такой регистр не всегда сопровождается последующим чтением (контролем остатка), но при этом надо точно понимать когда нужно блокировать, а когда нет. Так что в идеальном варианте «БлокироватьДляИзменения» нужное свойство, но где вы видели идеальные конфигурации ?
GROOVY, поправьте терминалогию, грязным чтением называется совершенно другие ошибки.
(79) frying, на мой взгляд с терминОлогией все правильно:
(80), «грязное» чтение (англ. dirty read) — чтение данных, добавленных или изменённых транзакцией, которая впоследствии не подтвердится (откатится);
На момент чтения ничего еще не изменилось. Иначе прочитать бы не удалось. При управляемых блокировках в транзакции проведения уровень изоляции READ COMMITED, что само собой исключает возможность грязного чтения.
(81) frying, ок. Как назвать чтение данных уже измененных но не зафиксированных параллельной транзакцией?
То, что Вы написали в вопросе и есть Грязное чтение. В статье описана другая проблема, которую решает или Repeatable read или Serializable. При проведении документов грязного чтения быть не может.
Извиняюсь, Repeatable read не решит.
Кем будет наложена блокировка на весь регистр:
— Сервером приложений (если это так то это ошибка в логике работы сервера приложений) ?
— MS SQL Server (такое вполне возможно т.к. MS SQL сам принимает решение что блокировать) ?
(8) hulio, вот это пожалуй лишнее — на документах с разумным количеством строк выигрыша от индексирования не получите, а замедление вполне реальное на создание индекса:
(8) hulio, судя по опыту с запросом получения остатков по партиям на MS SQL делать отбор в виртуальных таблицах остатков в виде подзапросов чревато нестабильностью времени выполнения запроса при не совсем актуальной статистике:
(86) ZLENKO.PRO, Да ладно, с таким запросом все примитивно очевидно. Вот если подзапрос к виртуальным таблицам, тогда да…
(87) и тем не менее факты вещь упрямая 🙂 условие в соединении таблиц отрабатывается MS SQL быстрее чем в параметрах виртуальной таблицы в виде подзапроса. Я проводил множество экспериментов по оптимизации запроса получающего остатки партий при проведении по партиям. Хотя это и противоречит «официальной» теории но так на MS SQL работает существенно быстрее даже при актуальной статистике, чем с отборами в виртуальной таблице:
По поводу других СУБД ничего сказать не могу по этому поводу.
Извиняюсь что редко пишу.
По вашей переписке — имхо вы оба уходите в частности, есть список «ограничений» и «условий» при которых алгоритмы работают, даже банальное количество строк в обсуждаемых таблицах могут поменять «подход» к алгоритму…
Делить Вам нечего: Павел рассказывает про массовый подход, а вы (88) про частный — как бы не корректно под общий знаменатель это все делать…
(89) Для общего случая лучше работает сначала отдельным запросом получить список номенклатуры и список складов и в виде параметра запроса их указать в отборе виртуальной таблицы вот так:
На истину в последней инстанции не претендую 🙂 Просто поделился опытом.
Меня больше интересует ответ на (84).
(89) Gilev.Vyacheslav, просто вот в том запросе по остаткам партий 1С применила массовый подход и страшно даже представить сколько сотен тысяч машино-лет потерянной производительности это стоило в масштабах страны. Все таки наиболее часто используется MS SQL (файловый вариант в расчет не берем).
(85) ZLENKO.PRO,
Я знаю, этот кусок кода я скопировал из статьи Павла
надо смотреть на количество строк во временной таблице, если там 2 строки, индекс сильно не даст выигрыша, но я бы не стал из этого делать «религию», потому что и время создания индекса милисекунды
если лень делать «исследования», и знаете что по полю временной таблице будет соединение, то индексирование более «надежно»
все начинает играть новыми красками, когда во временную таблицу приходит миллион строк )
(93) Gilev.Vyacheslav,
Это точно. Мне даже кажется, что эффект будет вполне заметен уже на 100+ строках 🙂
Модуль, написанный по «новой методике», примерно в 2-3 раза сложнее и длиннее (в строках), чем по «старой». Поэтому применять этот подход ИМХО нужно, только если припечет с блокировкой транзакций. В толково написанной нетиповой конфигурации мне страшно даже представить объем нагрузки на сервер, при котором проблема станет актуальной. А вот для типовых — да, но переписывать модули проведения задолбаешься.
(95) bulpi, конечно, оценивать эффективность методики по длине кода — это сильно…
(94) hulio, на 100 строках эффекта точно не заметите 🙂
(95) bulpi, если 2-3 пользователя то можно вообще не заморачиваться с методиками. А вот когда их под сотню и база уже несколько десятков гигабайт, то проблема с блокировками становится очень даже актуальной.
И как я уже писал качественно решить эту проблему помогает только переход на версионную СУБД.
Перевести типовую конфигурацию на «новую» методику не так уж и сложно — вполне реально (описано в (34)).
Я вместе с изучением теоретической части и практическими опытами перевел типовую УПП за 4 дня (2 дня читал мануалы и форумы, 1 день на кодинг, 1 день на тестирование). Правда контроль остатков товара по новой методике там уже был (я сделал еще раньше).
Если Режим = РежимПроведенияДокумента.Оперативный Тогда
Движения.СтоимостьТоваров.Очистить();
//17
Движения.СтоимостьТоваров.БлокироватьДляИзменения = Истина;
Движения.СтоимостьТоваров.Записать();
КонецЕсли;
На больших наборах это может приводить к заметному торможению .
На текущей машине около минуты на 1000.
В запросе остатков просто достаточно исключить обороты по документу, если они были