Стоп. Я когда выдирал алгоритм, специально поиском проверял, что это код нужен ТОЛЬКО для проверки одного ограничения, что количество товара который отгружается не больше количества товара который приходуется / оприходован. Я там даже пометку сделал
Вообще-то в процедуре ИнициализироватьДанныеДокумента собираются и, где это возможно, вычисляются все данные для проведения документа по регистрам и дальнейшей проверки на ненулевой остаток. В первую очередь для проведения. Кстати, в статье «Почему не 1С» вы в главе «Отсутствие ограничений и событий для значений регистров» не совсем разобрались зачем нужно получать значения из регистров перед записью и что с ними делается при записи. А именно, вычисляется — какие записи были изменены таким образом, что это может вызвать отрицательные остатки. И проверять отрицательный остаток только для тех регистров, в которых такое вообще могло произойти. А в вашей системе, выходит, агрегирование для контроля остатка производится безусловно, даже если этого можно и не делать? А строк, знаете ли, могут быть миллионы…
Знаете что такое premature оптимизация и правило Парето? Безусловно возможно есть случаи, где такая тонкая оптимизация может понадобиться.
Моя многолетняя практика 1С показывает, что если ERP-система выходит из рамок локальной сети в интернет, то разделение контекстов на клиент и сервер уже не является пустым звуком. Взять хотя бы загрузку данных в условный отчет комиссионера из того же экселя. Он может весить туеву хучу. Зачем гонять его на сервер? Вполне достаточно разобрать его полностью на клиенте и отправить минимальный объем данных на сервер, ну и так далее, боевые примеры могу приводить бесконечно.
А зачем тогда весь этот огород с:
Номенклатура В (
ВЫБРАТЬ Номенклатура
ИЗ Документ.РасходнаяНакладная.Состав
ГДЕ Ссылка = &Документ)
Если она сама все протолкнет и не «вызовет получение лишних данных».
Это чей-то мозговой клин. Программисты самой 1С — тоже люди. Можете смело удалить это условие из параметров виртуальной таблицы — план запроса не изменится.
Если Маша зашла в документ просто «посмотреть», то он не заблокируется. Блокировка начнет работать только при начале редактирования — то есть при изменении свойства Модифицированность открытого объекта.
Да, именно так — надо кричать «Маша дай отредактировать документ, когда ты его уже отпустишь». Ибо не заметив, что кто-то параллельно внес правку в открытый тобой документ, можно и счет клиенту не на ту сумму отправить… А потом ищи концы, какая там Маша что в этот момент делала. Так некоторые учетные системы можно превратить в полную помойку.
Нет, не вижу. Лично я вижу разные парадигмы обработки данных и поддержания их целостности у 1С и у вашего решения. В обоих случаях есть плюсы, а есть минусы. Если очень надо, то действительно, как сказал gennayo, очень просто сделать табличную часть документа не в виде табличной части, а в виде подчиненного документа или справочника. И даже достаточно конфигураций, которые именно так и работают. В основном WMS-ки, где, к примеру, сразу множество кладовщиков одну приемку делают. И это тоже очень просто, как дважды два — просто «ПКМ->Добавить» в конфигураторе. А еще есть множество ситуаций, когда над заказом работает пара менеджеров, и в текстовом поле Комментарий пишут важные замечания по заказу. В вашей демо-ERP вот прямо сейчас можно открыть два сеанса, в каждом сеансе по окну одного документа «Заказ (закупка)», допустим, номер 9080111, изменить и сохранить в них одно и то же поле, к примеру «Примечание», и сохранится только последняя правка, а правка первого сохранившего молча пойдет лесом. Базовая парадигма 1С — не допустить такого сценария ни при каких раскладах. Ваша — да и пофиг, если надо — сами лок делайте при открытии. И при этом вы утверждаете, что это прогрессивно.
Но это, согласитесь, костыль на регистрах. Все-таки парадигма 1С — изменение данных цельными блоками. Другое дело, что автор опять делит мир на олдскул и ньюскул, безапеляционно утверждая, что принцип работы 1С — это расшаренный по сети Excel по сравнению с Google Docs.
Насчет монструозных кусков кода. В контексте проблемы неэффективного получения данных вы приводили пример наполнения таблиц к проведению документа из, видимо, УТ. В частности, процедуру ИнициализироватьДанныеДокумента. Видимо, как пример избыточного получения данных и сложных танцев с бубном. Правда, свой контрпример вы привели (и здесь это подтвердили) как проверку очень простого ограничения вроде текущего остатка. А в 1С процедура проведения, для которой и собираются все эти таблицы, выполняет гораздо более широкий набор действий с объектами по определенной бизнес-логике. Это и расчет сопутствующих показателей для всех регистров, и контроль остатков, и различные блокировки на время записи документа, и даже проверка необходимости изменять записи в таблицах, если они не изменились с момента предыдущей записи. Вот по этому я и говорю — вы сравниваете выдранные из контекста боевых решений алгоритмы со своими академичными примерами, а это неправильно.
Насчет разделения на контекст клиента и сервера. Это сделано для уменьшения количества обращений к серверу. В вашем же случае как минимум необходимо постоянное получение обновленных данных об объекте с сервера, что не слишком-то оптимально. Ну или хотя бы постоянная проверка состояния. Опять же, по вашим словам — любая манипуляция происходит в едином контексте на сервере, от вашего клиента поступают лишь команды на манипуляцию. В 1С можно заложить множество бизнес-логики на исполнение только на клиенте, что заметно снизит количество обращений к серверу. И да, для написания максимально оптимального решения программисту необходимо понимать потоки данных Клиент-Сервер.
Далее, про представления. Вы сами на примере некорректно написанного запроса пытались показать, что виртуальные таблицы, к примеру, не подходят для решения такой простой задачи, как вывод остатков в динамическом списке номенклатуры, т.к. будут неоптимально обращаться сразу ко всей таблице остатков без фильтрации по номенклатуре… Хотите верьте хотите нет, но запрос для динамического списка
ВЫБРАТЬ
Товары.Наименование КАК Наименование,
ЕСТЬNULL(ТоварыНаСкладах.КоличествоОстаток, 0) КАК КоличествоОстаток
ИЗ
Справочник.Номенклатура КАК Товары
ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.ТоварыНаСкладах.Остатки(&Период, Склад = &Склад) КАК ТоварыНаСкладахОстатки
ПО (Товары.Ссылка = ТоварыНаСкладахОстатки.Номенклатура)
будет работать оптимально, и выбирать остатки только по тем товарам, которые в данный момент видны на экране пользователю. Более того, даже такой, казалось бы неоптимальный, запрос
ВЫБРАТЬ
СпрККТ.Ссылка КАК Ссылка,
ВложенныйЗапрос.Дата КАК ДатаПоследнегоЧека
ИЗ
Справочник.ККТ КАК СпрККТ
ЛЕВОЕ СОЕДИНЕНИЕ (ВЫБРАТЬ
МАКСИМУМ(ЧекККМ.Дата) КАК Дата,
ЧекККМ.ККТ КАК ККТ
ИЗ
Документ.ЧекККМ КАК ЧекККМ
СГРУППИРОВАТЬ ПО
ЧекККМ.ККТ) КАК ВложенныйЗапрос
ПО СпрККТ.Ссылка = ВложенныйЗапрос.ККТ
будет работать оптимально и не вызовет получения лишних данных
А если оба дописали примечание в документ, то прав останется последний. При этом первый будет уверен, что записал свои изменения. Вот ровно только что провел такой эксперимент в вашей демо-ERP, и все сработало по данному сценарию. В общем, спорное решение. Могу я предположить, что если кому-то по бизнес-логике понадобится реализовать механизм монопольного редактирования объектов, то он будет выглядеть монструозным и костылеватым, т.к. вы не поддерживаете этого на уровне платформы?
Круто ребята вбрасывают. В статье «Почему не 1С» в качестве примеров берут реальные, так сказать промышленные куски кода, которые будучи вырванными из контекста всегда будут выглядеть неадекватно и монструозно. А в этой статье в качестве решения проблем предлагается метод «Ну допустим, есть товар А с ценой Б и количеством В. Тогда сумму мы вычислим вот таким простым способом в одну строчку. Сравните с 1С.». Это называется по-другому, а именно «нечестный полемический прием».
Ну и, честно говоря, неглубокое понимание архитектуры 1С автором тоже не делает ему чести и доверия. Взять хотя бы ошибочную версию автора, что виртуальные таблицы 1С — всего лишь представления (view). Что заставило автора думать, что в их параметрах можно использовать только константы и не позволило решить такую простую задачу, как вывод в динамическом списке товаров их остатки по складам.
UPD 14:42
Изучаю вашу демку ERP. Ну что сказать… А где блокировка бизнес-объектов от изменения одновременно несколькими пользователями? Или так задумано —
Дак не запишется документ — напишет про несоответствие версий. Честь Маши не пострадала!
Вообще-то в процедуре ИнициализироватьДанныеДокумента собираются и, где это возможно, вычисляются все данные для проведения документа по регистрам и дальнейшей проверки на ненулевой остаток. В первую очередь для проведения. Кстати, в статье «Почему не 1С» вы в главе «Отсутствие ограничений и событий для значений регистров» не совсем разобрались зачем нужно получать значения из регистров перед записью и что с ними делается при записи. А именно, вычисляется — какие записи были изменены таким образом, что это может вызвать отрицательные остатки. И проверять отрицательный остаток только для тех регистров, в которых такое вообще могло произойти. А в вашей системе, выходит, агрегирование для контроля остатка производится безусловно, даже если этого можно и не делать? А строк, знаете ли, могут быть миллионы…
Моя многолетняя практика 1С показывает, что если ERP-система выходит из рамок локальной сети в интернет, то разделение контекстов на клиент и сервер уже не является пустым звуком. Взять хотя бы загрузку данных в условный отчет комиссионера из того же экселя. Он может весить туеву хучу. Зачем гонять его на сервер? Вполне достаточно разобрать его полностью на клиенте и отправить минимальный объем данных на сервер, ну и так далее, боевые примеры могу приводить бесконечно.
Это чей-то мозговой клин. Программисты самой 1С — тоже люди. Можете смело удалить это условие из параметров виртуальной таблицы — план запроса не изменится.
Насчет разделения на контекст клиента и сервера. Это сделано для уменьшения количества обращений к серверу. В вашем же случае как минимум необходимо постоянное получение обновленных данных об объекте с сервера, что не слишком-то оптимально. Ну или хотя бы постоянная проверка состояния. Опять же, по вашим словам — любая манипуляция происходит в едином контексте на сервере, от вашего клиента поступают лишь команды на манипуляцию. В 1С можно заложить множество бизнес-логики на исполнение только на клиенте, что заметно снизит количество обращений к серверу. И да, для написания максимально оптимального решения программисту необходимо понимать потоки данных Клиент-Сервер.
Далее, про представления. Вы сами на примере некорректно написанного запроса пытались показать, что виртуальные таблицы, к примеру, не подходят для решения такой простой задачи, как вывод остатков в динамическом списке номенклатуры, т.к. будут неоптимально обращаться сразу ко всей таблице остатков без фильтрации по номенклатуре… Хотите верьте хотите нет, но запрос для динамического списка
будет работать оптимально, и выбирать остатки только по тем товарам, которые в данный момент видны на экране пользователю. Более того, даже такой, казалось бы неоптимальный, запрос
будет работать оптимально и не вызовет получения лишних данных
Ну и, честно говоря, неглубокое понимание архитектуры 1С автором тоже не делает ему чести и доверия. Взять хотя бы ошибочную версию автора, что виртуальные таблицы 1С — всего лишь представления (view). Что заставило автора думать, что в их параметрах можно использовать только константы и не позволило решить такую простую задачу, как вывод в динамическом списке товаров их остатки по складам.
UPD 14:42
Изучаю вашу демку ERP. Ну что сказать… А где блокировка бизнес-объектов от изменения одновременно несколькими пользователями? Или так задумано —