Доброго времени суток.
Подскажите. пожалуйста, можно ли в 1С проиндексировать не значение поля, а значение выражения языка запросов 1С? Есть регистр сведений с одним измерением (Рейс) и одним ресурсом (Статус). У документа Рейс есть поле Исполнитель. Надо получить все записи РС по определённому исполнителю, но сам исполнитель в этом РС не нужен. Спасибо за внимание и помощь :)

Нет

(1) Спасибо, 1С такой 1С...

(2) Это не 1С, это кривые руки.

(3) Интересный аргумент. И как бы сделал человек с прямыми руками?

(4) Изменил бы задачу.
Или решил бы проблему другими средствами

(4) Добавил бы индексированное измерение в регистр. Если по нему часто фильтровать нужно и если это тормозит выборку.

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

Но все зависит от конкретных объемов - тут бездумно рецепты раздавать сложно.

(5) Есть ли у вас какие-либо конкретные идеи? Если не хватает информации, то я с удовольствием отвечу на ваши вопросы.
(6) Добавление индексируемого поля в РС только для фильтра - это вынужденная мера, поскольку 1С не предоставляет индексов по выражению. Среднее количество документов Рейс в день - около тысячи, применённое решение должно работать не менее пяти лет (это обусловлено сроком технической поддержки), поэтому второй вариант не применим.

(7) И все это, конечно, на файловой базе. Ага.

(7) Побойтесь Бога! Второе января! А Вы предлагаете за Вас поработать!

Денормализуйте таблицу, добавьте исполнителя в виде индексированного измерения.

Мера не вынужденная - 1С использует различные СУБД. И редко какая позволяет такие сложные индексы использовать. Даже базовый для 1С MS SQL это позволяет делать через попу только.

(7) Создайте в скульной базе дополнительную таблицу для нужных связей с нужными полями.
Джобом скуля или регламентным заданием 1С актуализируйте в ней данные.

(10) Угу. Критерий отбора называется.

(10) + В результате SQL подхватит два кластерных индекса и будет ему щастье.

Хотя не, не будет... С такой постановкой и отношением в (2) его два миллиона записей упрутся в диск

(8) Вероятнее всего будут использоваться MSSQL или PGSQL + сервер 1С.
(9) Я не прошу никого поработать за меня, просто спрашиваю совета у джедаев. Я так и понял, что остаётся только денормализовать таблицу. Но это не хороший вариант, в итоговом решении получается очень много таких таблиц. Стоимость владения этой системой будет высокой.
(10) У меня нет гарантий, что будет использован mssql. Конфигурация будет поставляться в несколько компаний. И я не понимаю как это может мне помочь и чем это лучше индекса по выражению, даже если реализовать.
(11) Критерий отбора отображается в индекс таблицы по выбранному полю.
(12) Вы ошибаетесь, может быть только один индекс для кластеризации таблицы. Дополнительную информацию можете посмотреть по ссылке: https://msdn.microsoft.com/ru-ru/library/jj835095(v=sql.120).aspx#Clustered

(13) Денормализация никакого отношения к стоимости владения не имеет.

Неважно какой сервер у Вас будет использоваться. Важно то, что 1С не работает таким способом. И не будет с крайне высокой степенью вероятности.

(0) Если часто требуется отбор записей регистра по Исполнител. - почему бы его туда не добавить, а если это разовый запрос, то чем не устраивает использование в запросе конструкции "ГДЕ Рейс.Исполнитель=&Исполнитель"?

(14) 1С сам по себе не способствует поддержанию кодовой базы в согласованном состоянии. Это остаётся на совести программиста. И сильно зависит от его квалификации и памяти. Чем больше будет изощрений для обхода технических сложностей, тем более квалифицированный персонал нужен для поддержки и доработки функционала.
(15) Это не разовый запрос. При добавлении дополнительного поля теряется ясность изложения и немного пухнет база. Второе не критично, но вот с первым я уже наелся и хотелось бы, конечный продукт был понятен и студенту.

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

Нормальное решение для трехзвенки.

Вообще в ТСе бывалого дельфиста вангую я, а это диагноз :(

(0) а в чем конкретно проблема то? Запрос долго выполняется? Или это сферическая проблема, высосанная из пальца?

(17) Не делфист и не бывший :) Пишу бэкэнды на .net + pgsql Давным давно я был 1С-ником, по старой памяти ко мне пришла на поддержку отраслёвка.
(18) Запрос выполняется недостаточно быстро.

(19) недостаточно быстро - это сколько?

(16) Позвольте, необходимость в отборе данных по реквизиту есть, но от самого реквизита вы решительно отмежевываетесь. В этом моменте есть чисто диалектическое противоречие, которое как правило ошибок не прощает, и подобные напряжения внутри системы в любом случае чреваты боком. Я не в теме, но на вскидку вам необходимо переосмыслить нечто большее, тут не поможет программное решение из серии "добавлять не хочу, но надо чтобы работало быстро".

(20) В тестовой базе с миллионом записей около 60 секунд. Запрос выполняется внутри транзакции проведения документа.
(21) Противоречий не вижу. Задача индексирования по выражению не часто встречается. Суть задачи в том, чтобы агрегировать статусы рейсов в статус исполнителя и по итогам сделать какие-то действия.

(22) Пора бы уже выложить запрос и план его выполнения

(23) Запрос:
ВЫБРАТЬ
    Статус
    ,КОЛИЧЕСТВО(Статус) КАК КоличествоРейсов
  ИЗ
    РегистрСведений.СтатусыРейсов
    ВНУТРЕННЕЕ СОЕДИНЕНИЕ Документ.Рейс
      ПО
        Рейс = Ссылка
  ГДЕ
    Исполнитель = &Исполнитель
  СГРУППИРОВАТЬ ПО
    Статус
    |");

(23) План чуток позже. До тестового mssql не добраться, похоже нет электричества.

(22) проведение документа овер 60 сек? Ужас!!!
Вы точно давно 1С курили. На допроведение по регламенту не согласны?

(24) Ну да, ну да... Это же все потому что
1С сам по себе не способствует поддержанию кодовой базы в согласованном состоянии. Это остаётся на совести программиста. И сильно зависит от его квалификации и памяти. Чем больше будет изощрений для обхода технических сложностей, тем более квалифицированный персонал нужен для поддержки и доработки функционала.


1) Включи индексирование по полю Исполнитель в документе Рейс без упорядочивания. Это построит индекс "Исполнитель + Ссылка" по таблице документа
2) Перенеси условие отбора "Исполнитель = &Исполнитель" в условие соединения, чтобы индекс начал использоваться.

(27) Индекс по реквизиту документа имеется. Для внутреннего соединения не имеет значения где располагаются условия. В стародавние времена условия соединения писали в предложении where, точно не помню, то ли sql-86, то ли sql-89. Оптимизаторы запросов нормально относятся к этому.

Решил я задачу так - почистил РС от финального статуса документов. Теперь всё нормализовалось. Всем спасибо.

(28) ansi "то ли sql-86, то ли sql-89" никогда не существовало.
Вообще лучше историю SQL поучи. Станет задачи по нормальному делать.

>(29) ... sql-89" никогда не существовало
Где-то в интернетах ( https://ru.wikipedia.org/wiki/SQL-92 ) считают по-другому.

>(27) условие отбора "Исполнитель = &Исполнитель" в условие соединения
Это разрушает логику (снижает читабельность) запроса. Соединения показывают связи источников. Секция ГДЕ показывает отбор данных

>(28) Для внутреннего соединения не имеет значения где располагаются условия ... Оптимизаторы запросов нормально относятся к этому
Это действительно объективный факт. Можно его дополнительно уточнить, что оптимизаторы нормально относятся в постановке условий отбора на ведущие источники и в случаях внешних соединений.

>(24) Запрос
Я так понял, исходя из (0) и (24), что в регистре нет истории статусов. Тогда зачем делать регистр? Почему нельзя положить статус в сам документ?

Если история статусов есть, то запрос (24) даст неадекватный результат - количество записей со статусами по исполнителю. Что это показывает? Количество рейсов, завершенных рейсов, выполняемых рейсов?

Проблема в постановке задачи, точнее в том, что нет формулировки конечного результата на простых бизнес-терминах без использования слов из программирования вообще и 1С, в частности.

(28) от финального статуса
Оказывается еще и временной разрез есть... =)

(30) "Соединения показывают связи источников."

ВНУТРЕННИМ Соединением отлично фильтруется таблица.

>(32) ВНУТРЕННИМ Соединением отлично фильтруется
Я же не спорю с этим утверждением.
Я говорю про другое, что фильтрация в соединении снижает читабельность запроса, перенося логику отбора записей в условия связи таблиц.
К сожалению, большинство программистов не понимают соединений вообще, а уж добавление отборов в условия соединений убивает у них мысль окончательно. И с этим приходится считаться.

(33) Внезапно стало интересно, если вас с ТС вместе свести, вы после обсуждений стоимости владения, читабельности запросов и квалификации персонала задачу-то решите?

Или без того самого персонала уже никак?

Чета я так и не понял, в чем конкретно была оптимизация, сколько запрос стал выполняться после оптимизации и поможет ли в данном случае перенос условия "Исполнитель = &Исполнитель" в условия соединения, потому как звучат прямо противоположные мнения по этому поводу.

> (30) Я так понял, исходя из (0) и (24), что в регистре нет истории статусов. Тогда зачем делать регистр? Почему нельзя положить статус в сам документ?

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

> Проблема в постановке задачи, точнее в том, что нет формулировки конечного результата на простых бизнес-терминах без использования слов из программирования вообще и 1С, в частности.

На основании текущих статусов рейсов надо выставить текущий статус исполнителя рейсов. Например, планируется три рейса на исполнителя, надо установить ему статус "Загружен работой под завязку", если планируется большее количество, то статус "Ошибка планирования". (Это просто пример, рабочие статусы узкоспециализированные, но суть пример отражает)

(34) Если бы вам доводилось заниматься поддержкой решений продаваемых по всей России и за её пределами, а кроме этого работающих 24/7, то вы нас поняли бы лучше. Пока вам не позвонят в 2-3 часа ночи из Владивостока за консультацией, любые наши пояснения будут выглядеть для вас забавными.

(35) Перенос условия не поможет. Оптимизация заключалась в удалении 99.9% записей из РС. Теперь считается, что раз документа в РС нет, то значит он завершён. Время выполнения запроса составляет 370-630 мс.