Вот все знают, что если у реквизита поставить признак "индексировать", то создастся индекс, состоящий из 2-х колонок - самого реквизита и ссылки.

А если создать критерий отбора - то индекс создастся из одной колонки - только значения реквизита.

Зачем так сделано?

Ну и голосовалка, что лучше :)

(73) Абсолютно такого же мнения.

(73) обезьяны уже получили гранату в виде запросов, после этого индексы не так страшны.

И update тоже не дают по этому же поводу.

А вот cast могли бы дать, че, жалко штоле?

(72) Я ж говорю, я не знаю из каких соображений разработчики такие индексы создают.
Это было единственное объяснение пришедшее на ум, насчет методов.

(75) Фигня.

Запрос писать надо, думать.
А индекс - потыкал мышью - и вуаля - вот он!

(76) думаю, что update не дают, так как вся логика работы системы построена на работе в один момент с одним объектом.
И на текущий момент нет понимая как делать апдейт таблицы, если весь код работает с каждым объектом данных.

(78) Фингя. Открыл конструктор запроса - потыкал мышкой и вуаля - вот он!

(73) никогда не видел конфы, в которых индексировать везде стоит стараниями "программиста"?

(76) Вот с cast реально засада.
(75) Не, ну запросы приличные это хорошо. Если криво написан, не так сильны последствия, и быстрее исправить, чем здоровенный индекс, который используется в одном единственном запросе, зато пишется постоянно.

(82) Кривой индекс хорошо виден как и кривой запрос.

(81) Не, такого не видел :).
Меня еще убивает, нахрена по умолчанию платформа при создании реквизита ставит использовать полнотекстовый поиск.
Может это можно где-то поправить, не знаю.

(83) Это если хотеть его видеть, кривой индекс. А то будет как в (81).

(60) Въехал. С точки зрения получения через критерий необходимого простого индекса в таблице, вполне имеет право на жизнь.

(15) Ах воооот оно как... Вот это, кстати, аргумент.

(87) -> (66)(68)(69)

Вот будет суперконфигуратор - там будет ВСЕ

(88) кстати, есть еще одно потенциальное применение такого составного индекса, это сортировка списков по реквизиту. Учитывая что ссылка в индексе дает уникальность и обеспечивает постоянный порядок следования.
Хотя опять же, сортировка списка возможна по нескольким полям, и тут это преимущество теряется.

(90)+ Вроде у меня уже фантазия заканчивается, где еще можно поиметь профит от такого составного индекса по реквизиту :).

(0) вроде же типа и ссылки. и все понятно, про вариант 2 viktor_vv рассказал, а вариант 1 для сравнения на равно и В

(90) для сортировки - "индексирование с доп упорядочиванием", оно еще добавляет n колонок на представление

(93) Ну почему только с доп упорядочиванием для сортировки. Если установить просто индексирование на реквизите, то быстрая сортировка тоже становится доступной.

(94)+ А без ссылки в индексе, порядок сортировки в пределах одинакового значения реквизита был бы произвольным. И при допупорядочивания, все равно добавляют ссылку в индекс, опять же для обеспечения постоянного порядка следования в пределах одинакового значения реквизита и поля упорядочивания.

(94) Упс. Это для справочников.

(96)+ Точнее сказать, это для реквизитов примитивного типа у справочников и документов.
Вот с агрегатными уже ХЗ. Для сортировки реквизиты агрегатного типа с признаком Индексировать недоступны.

(88) Хм... С другой стороны получается, что индекс по 2-м колонкам может быть нужен лишь для Справочники.НашСправочник.НайтиПоРеквизиту(...). То есть, это может быть применимо в случаях, если

1. Мы уверены, что значение реквизита, которое мы задаем, встречается у одного и только одного элемента справочника НашСправочник.

2. Нам сгодится совершенно любой элемент справочника НашСправочник, имеющий заданное значение реквизита.

Вопросы:

1. Часто ли бывают ситуации описанные в п.1 и п.2 данного сообщения?

2. Какие еще могут быть ситуации, когда может быть индекс по 2-м колонкам (НашРеквизит, Ссылка) как при стандартном индексировании НЕ через критерий отбора?

+(98) >когда может быть индекс по 2-м колонкам
когда может быть НУЖЕН индекс по 2-м колонкам

Ужас! Почему на этом форуме нельзя просто подправить ошибку в сообщении?

СТО!

(99) 1С ошибок не прощает!

Fragster, viktor_vv что скажете на (98) ?

(98) Я пока придумал еще тоько сортировку списков по реквизиту примитивного типа в (90).

(103) Ну еще можно п.3 добавить в (98) - когда нужно зачем-то получить список элементов НашСправочник, имеющих заданное значение реквизита не трогая при этом основную таблицу справочника.

НООО ведь, как правило, надо еще и хотя-бы Представление элемента получить (к примеру, для выпадающего списка)- значит надо не по 2-м, а по 3-м колонкам индекс делать - (НашРеквизит, Ссылка, Наименование).

P. S. Интересная ветка для людей, собирающихся сдавать "1С:Эксперт по технологическим вопросам крупных внедрений".

+(104) Вот для этого, вероятно, и нужно "Индексирование с доп. упорядочиванием" http://1cexpo.ru/informacziya/28-indeksy-tablicz-bazy-dannyx-1s-predpriyatie-82.html, что, в общем-то, уже говорилось в рамках данной ветки.

(104) кстати, на представление многие забивают, а потом если профайлером глянуть - куча запросов тех самых представлений идет

(102) Насчет ситуаций, когда это может понадобится для реквизита согласен. Но обычно индексировать имеет смысл ставить на реквизит с высокой уникальностью значений.
Насчет получить список элементов по значению реквизита, там выше давали насчет Выбрать() с отбором, получается тянет в выборку и остальные реквизиты, так что вряд ли тут выигрыш.
А НайтиПоРеквизиту() не возвращает список, а только первый найденный.

(105) Не думаю что доп. упорядочивание для облегечения получения представления сделано. Имхо для получения необходимого порядка по индексу.
А представление по любому тянут потом отдельно, как в (106).

(106) для 8.3 уже не так актуально, ведь там можно делать свое представление.

(107) По-моему, в (98) чрезвычайно редкие ситуации. Вообще склоняюсь к тому, что
- Справочники.НашСправочник.Выбрать(...)
- Справочники.НашСправочник.НайтиПоРеквизиту(...)
выбросить надо из платформы - все что они могут, прекрасно делается запросами, да и редко они используются что-то.
ПолучитьСсылку() - считаю нужным оставить (!).
Насчет
- Справочники.НашСправочник.НайтиПоКоду(...)
- Справочники.НашСправочник.НайтиПоНаименованию(...)
спорный вопрос - штука весьма практичная, хотя и грязная (правда, я лично ими не пользуюсь - предпочитаю ПолучитьСсылку()).

(109) ты думаешь, количество запросов к базе от этого уменьшится, если не получить в искомом запросе .Представление?

(111) если посмотреть как работает получение представления, то видно, что хватает и кластерного индекса объекта.

(112) да. но есть разница, получить все одним запросом или получить ссылку, а потом 50 запросов, хоть и по кластерному индексу?

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

(113) Может стоит добавить в голосовалку "Индекс по трем колонкам" (Реквизит, Представление, Ссылка)?

(113) а где у тебя 50 запросов идет?

(110) Ну вот и есть ощущение, что для реквизитов индексирование сделали по образу и подобию с наименованием и кодом.

(115) сделай так:
Запрос = Новый Запрос("Выбрать первые 50 Спр.Ссылка из Справочник.Номенклатура");
Выборка = Запрос.Выполнить().Выбрать();
Пока Выборка.Следующий() Цикл
  Сообщить(Выборка.Ссылка);
КонецЦикла;

и глянь профайлером, что происходит, когда ты этот код выполняешь

(117)+1. И при получении данных в списках такая же хня скорее всего, даже если там только колонку с представлением оставить.

(117) Ага... Начинаю догадываться уже!
Или когда в отчет выводишь все это безобразие!

(118) нет, там иначе работает.

(117) ну если ты пишешь такой колхоз, то сам и виноват.

(118)(119) ну, по крайней мере СКД умная

(120)+(122) Ок.

(120) Кэш какой-то задействуется, что ли?
(122) Это СКД, а вот если "дедовским" способом...

(117) ведь ты сам знаешь, что система не вытаскивает представление при таком запросе, и будет его получать при таком коде, так же как и получение свойств через точку приводит к получению всего объекта из базы с последующим кэшированием этой какули.

(121) ага, Сообщить("Недостаточно номенклатуры " + Номенклатура + " на складе " + Склад + " для выполнения операции") = +2 запроса к БД

(126) ну да, поэтому в типовых идет НоменклатураПредставление и СкладПредставление.

(122)(124) динамический список получает из базы данные по основному запросу, а потом бегает по таблицам объектов и собирает представления выводимых данных.

(128) проверял?

(128) Ого! Это что еще за сырой деМОнический список?! Наверное недоработка разработчиков платформы 1С - надо написать на [email protected], если это так.

(129) нет, сам придумал

(130) в этой части не сырой. это такая оптимизация работы.

(132) Вот это да!!! В каком смысле оптимизиция !?

(133) Бобер просто попутал "Динамическое получение данных" с построчным получением представлений для ссылки, как было в обычных списках.

(134) Так вроде ж я это и имел ввиду в (118), говорят не так.
Это наверное ще надо уточнять какие списки имеются ввиду УФ или в обычных формах.

(133) например динамический список вытягивает 10 различных ссылочных полей + какие-нибудь остатки и цены или например поле составного типа. После основного запроса, который все это вытягивает из базы, платформа по отдельности тащит представляния для каждого типа (выбрать наименование из .. где ссылка В (&Список)). А если-бы все это тянулось разом, то: это был-бы запрос-монтр и не факт, что оптимизатор sql не затупил-бы от такой "наглости".

(136) Че-то мне кажется в основном запросе не так уж и напряжно это было.
Прилепили бы левых соединений туда, по индексированному полю ссылка.

Да, Бобер прав. Проверил.
Но хоть сразу, для всех одинакового типа, скопом. И это хорошо.

Динамическому не хватает Временных таблиц, это единственное что ему нужно. И что его спасет.

(134) (135) в динамическом списке обычных форм платформа сразу тащит представление левым соединением для всех ссылочных объектов.

(134)(136) Надо-же... Надо-бы проверить все эти утверждения/допущения посредством профайлера.

(140) Я проверил. Бобер прав.

(138) О! Кажется и проверять (140) уже не очень-то надо.

(118) почему у тебя при получении данных идут еще запросы с ходу не сказать, то думаю что пример в (117) даст тебе ответ.

(143) Не. Это предположение было. Теперь понятнее.

(138) Не будет скорее всего временных таблиц в динамическом. Слишком большие накалдные расходы.

(137) полностью согласен, но теперь можно ваять текст запроса для динамического списка и 1с перестраховывается. Они и сами 10 лет говорили, что динамический список <> отчет, а теперь в динамических списках сложные вычисления задолжности, расчет статусов и еще ведро всякого.

(145) В большие расходы - не верю. В то, что не будет - верю.

(145)+ Как бы нафига такой список, где потребуется для вывода использовать временную таблицу. Это уже к отчету ближе.

(148) Остатки и последние цены.

Если уж 1С режет руки криворуким обезьянам - пусть режет их полностью и убирает Виртуальные таблицы.

(147) Там ввод-вывод на диск идет. Ну да, может в кеше быть, но в общем случае, дополнительный ввод-вывод на диск не есть гуд, для настолько часто выполняемого запроса.

(149) там нужно подшаманить в параметрах вирт. таблиц расширением запросов СКД и будет хорошо работать без временных таблиц

(152) Никак там не подшаманишь, не глупи.

(146) Согласен, перестраховываются. Это как с произвольными составными индексами. Технически, думаю, не сильно сложно их сделать, но боятся.

(151) Редко, когда памяти не хватает. Бред. Мелочи.
Не глупите.

Когда виртуальная таблица без фильтра просчитывается - там этих таблиц в 100500 раз больше пишется.

(153) могу позакать, ты охухеешь

(154) Скажу тебе больше - технически - все уже ПОЧТИ работает.

(156) Давай! Надеюсь, я тебя разозлил, и ты мне докажешь, что я не прав.

(158) не, не разозлил, я сам охухел, когда увидел результат.

Не нравиться, боятся, что будет писать на диск - можно заюзать #table - объект SQL чисто в памяти.

(159) Давай, не томи.

[email protected]

(159) Так так так, какой интересный поворот ))

(157) Насчет предопределнных составных индексов в курсе, я имел ввиду технически дать возможность самим лепить в конфигураторе произвольные составные индексы. Проблем-то никаких, чисто боятся утонуть от обращений с криками все пропало шеф, все тормозит нещадно.

(155) Как по мне для динамического списка было бы полезнее в selecte коррелированные подзапросы сделать.

(161) не надо в почту, надо сюда

(163) Понаделают программисты 1С кучу индексов "на всякий случай" и... Все в этой ветке понимают что будет дальше.

(166) Я о том же.

(161) фигульки в личку.
не так давно щупал динамические списки, и вот результат:
http://infostart.ru/public/169685/

пункт 4 и 5.
PS Единственное, что 1с не будет фиксить НО по пункту 4.

(168) Афигеть !

(163) думаю, что скоро такая фишка появится, как появился пункт "стандартные реквизиты". И туда перенесут, все настройки индексов.

Жесть.

А уж как я извращался, пытаясь основную таблицу в временную засунуть.

(169) Тролль!

Покажите это Евгению Щекину.