КритерийОтборану формально любую тз с подходящей типизацией можно затолкать в скд. просто через внеш. источники это будет менее гиморойно

но насколько хороша реализация этих прокладок

У меня были проблемы при загрузке около 40-50 тыс. строк в СКД через ТЗ, были жуткие тормоза порядка 30 сек. (возможно из-за режима совместимости с 8.2), пришлось через ADO делать Update в служебный справочник (с update statistics естественно), а дальше уже из этого справочника делать СКД запрос.

И да ВнешниеИсточники не позволяют массовый insert\update, только построчный. А в режиме совместимости с 8.2 и с чтение есть какие то ограничения в запросах.

AHDPvitkhv,

А почему для хранения выбран справочник, а не регистр сведений?

Потому как Элемент справочника есть:
Поле 1: GUID по NEWID() (ссылка), SEQUENCE ID не нужен так как справочник Трункейтиться раз в месяц.
Поле 2: Excel файл (ХранилищеЗначений) тип image(varbinary(max) если без режима совместимости и MSSQL>2008). Тут можно было бы и контрольной сумой файла обойтись. Такой себе аналог FileStream, который мне не разрешили развернуть.

Дальше:
Первая ТЧ есть сам Excel файл, уже загнанный по полям в таблицу 1С. Используется, что бы не читать огромные Excel файлы из файл стрима, по несколько раз, т.е. по сути кэш файла.
Вторая ТЧ уже для запроса СКД перед заливкой в нее используется различные алгоритмы обработки Артикулов из Excel средствами MSSQL и соединения с нашим справочником номенклатура.

Все это сделано ради скорости, на всю эту обработку уходят миллисекунды.

AHDP, да и к тому же независимый РС в режиме совместимости имеет поле PrimaryKey binary(16). Тот же справочник по сути, никакой разницы.

Программист 1с,
Да

Программист 1с,
Именно для этой разработки я впервые использовал систему трансляции в ADO запросы для того, что бы писать запросы в метаименах 1С. Для этого я использовал SQL+ , который пришлось серьезно переработать. В стандарте SQL+ умеет разбирать только один запрос (т.е. никаких временных таблиц, кореллированных подзапросов, CTE и т.д.) и то криво. Я так понял, что автор SQL+ стремился сделать возможным использование конструктора запросов 1С, для ADO запросов. Не понимаю, почему так все помешаны на конструкторе запросов, доходит до того, что без конструктора даже запросы в текcтовом виде читать не умеют. Я использую конструктор, чтобы накидать вначале таблицы да поля и для форматирования запросов, и то не всегда. В итоге транслятор SQL+ дольше компилировал запрос, чем этот запрос выполнялся. В абсолютных цифрах это не очень долго конечно, но так или иначе пришлось сделать кэш запросов. Если контрольные суммы метазапросов совпадают, уже подготовленный запрос берется из кэша, без обработки SQL+. Подсмотрел я такую систему у SQL сервера, он точно таким же образом кэширует планы запросов и если текст запроса не менялся, SQL сервер дает уже готовый план, там конечно все сложнее, но такая система тоже присутствует. В итоге запрос компилируется из метатекста только однократно, дальше если текст запроса не меняется, время на его компиляцию уже не тратится.

КритерийОтбора
вероятно из-за того что один "мудрый" человек в 1с решил, что на строку в регистрах ссылаться негоже. и понеслись костыли "доступно и всерьез"

а потом героически начинают преодолевать трудности заботливо созданные самим себе чуть ранее

"ДанныеПодбораСотрудника" в ЗУП с измерением "ИдентификаторЗаписи" - улыбается и машет

При чем как я уже говорил, в непериодическом РС существовал уникальный идентификатор записи на уровне таблицы SQL, если 1С в режиме совместимости с 8.2, то существует. Только я там сверху неправильно написал, называется это поле _SimpleKey. В свежих релизах и без режима совместимости это поле по моему отсутствует.

Для периодических РС в ЗиУП сделали такую хрень . Как там написано: т.к. писать правильные запросы программисты 1С все равно не умеют, а сама 1С для ВТ периодического РС не хочет (я думаю не может :)) избавится от подзапроса, 1C нам представила механизм представлений. Это вообще дно, теперь программисты 1С вообще перестанут уметь писать запросы, даже с помощью конструктора.

КритерийОтбора
вероятно из-за того что один "мудрый" человек в 1с решил, что на строку в регистрах ссылаться негоже.

"ДанныеПодбораСотрудника" в ЗУП с измерением "ИдентификаторЗаписи" - улыбается и машет

Вы не поверите, первый вариант у меня работал через регистр сведений и было у него поле УИД :-). Этот регистр до сих пор болтается в конфигурации.

А так конечно выбор справочника в итоге был обусловлен прежде всего, необходимостью кэшировать файл. В итоге потребовалось бы делать несколько РС. Да и со справочником данная система выглядит логичнее.

В принципе данный справочник можно и не трункейтить, держа в нем всю историю файлов и даже кэш файла. Переделка на SEQUENCE ID дело получаса, а ТЧ справочника имеет кластерный индекс _IDRref+_KeyField, поэтому деградации времени на операции вставки не будет и производительность останется на прежнем уровне.

КритерийОтборакакой-то наркоман написал внутреннее соединение сотры с ДанныеПодбораСотрудника по ссылка = ссылка и ссылка.наименование = ДанныеПодбораСотрудника.наименование


Я думаю, соединение по наименованию написали из-за того, что бы попасть в Индекс _ReferenceXXX_ParentDescr. Так что все не так однозначно.

КритерийОтборавсе они умеют. если не заставлять их сношаться с кривоногой БСП, довести до ума язык запросов и устаканить структуру данных.


Не знаю, не знаю. Вот там, где я решал эту задачу сидит 3 программиста.

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

У третьего весь весь код требует оптимизации, даже самый простой. Оптимизировал простую его обработку, которая колбасила по 16 часов и ее просто обрубали т.к. не могли дождаться конца, до 20 секунд.

У первого и второго запросы в СКД оптимизируются в 5 раз, везде.

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

У всех трех динамический генерация СКД, запросов и кода в зависимости от условий, вызывала священный трепет.

Так третьего программиста по итогу уволили да и то, так как грубил юзерам.

А первых двух не то, что ни уволят никогда, их пытаются удержать всеми правдами и не правдами.