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

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

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

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

ну и да - если поставить "с доп упорядочиванием" - то еще и поле представления туда запихается

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


В критерии отбора - ссылку из индекса получать не надо.
Попробуем плясать от этого?

(2) почему не надо в критерии отбора?

(3) ХЗ.

(4) ну реально, критерий отбора - это же не физическая таблица

а что значит индекс с дополнительным упорядочиванием?

(3) Концепция в (0) прекрасна.
Ей (концепцией) надо ткнуть какого-нибудь Одавида, который кричал про убогость индексов в 1С.
Гораздо чаще надо получить Ссылку на Контрагнета по ИНН, чем Наименование контрагента по ИНН.

(5) Я не разбирался в критерии отбора.

Может там, при выполнении Критерия отбора - выбираются все поля записи и полюбому будет lookup, так нафига в индекс пихать Ссылку.

(7) Гораздо чаще нужно получать ссылку на контрагента по инн и кпп ))

(10) Получите indexseek + lookup

Да, возможности Общих индексов на несколько полей не хватает в 1С, но да не критично.

А какой смысл делать отбор по значению реквизита, а затем еще и по ссылке внутри одного значения реквизита??? Кажется, что лучше...

вот так работает:

exec sp_executesql N'SELECT
T1.IDTRef,
T1.IDRRef
FROM (SELECT
P1 AS IDTRef,
T2._IDRRef AS IDRRef
FROM _Document142 T2 WITH(NOLOCK)
WHERE EXISTS(
SELECT 1
FROM _Document142_VT1884 T3 WITH(NOLOCK)
WHERE T2._IDRRef = T3._Document142_IDRRef AND (T3._Fld1886_TYPE = @P2 AND T3._Fld1886_RTRef = @P3 AND T3._Fld1886_RRRef = @P4))
UNION ALL SELECT
@P5 AS IDTRef,
T4._IDRRef AS IDRRef
FROM _Document187 T4 WITH(NOLOCK)
WHERE EXISTS(
SELECT 1
FROM _Document187_VT3790 T5 WITH(NOLOCK)
WHERE T4._IDRRef = T5._Document187_IDRRef AND (T5._Fld3800_TYPE = @P2 AND T5._Fld3800_RTRef = @P3 AND T5._Fld3800_RRRef = @P4))
UNION SELECT
@P5 AS IDTRef,
T6._IDRRef AS IDRRef
FROM _Document187 T6 WITH(NOLOCK)
WHERE EXISTS(
SELECT 1
FROM _Document187_VT3790 T7 WITH(NOLOCK)
WHERE T6._IDRRef = T7._Document187_IDRRef AND (T7._Fld3801_TYPE = @P2 AND T7._Fld3801_RTRef = @P3 AND T7._Fld3801_RRRef = @P4))
UNION ALL SELECT
@P6 AS IDTRef,
T8._IDRRef AS IDRRef
FROM _Document153 T8 WITH(NOLOCK)
WHERE T8._Fld7075_TYPE = @P2 AND T8._Fld7075_RTRef = @P3 AND T8._Fld7075_RRRef = @P4
UNION ALL SELECT
@P7 AS IDTRef,
T9._IDRRef AS IDRRef
FROM _Document161 T9 WITH(NOLOCK)
WHERE T9._Fld2657_TYPE = @P2 AND T9._Fld2657_RTRef = @P3 AND T9._Fld2657_RRRef = @P4
UNION ALL SELECT
@P8 AS IDTRef,
T10._IDRRef AS IDRRef
FROM _Document164 T10 WITH(NOLOCK)
WHERE T10._Fld2815_TYPE = @P2 AND T10._Fld2815_RTRef = @P3 AND T10._Fld2815_RRRef = @P4
UNION ALL SELECT
@P9 AS IDTRef,
T11._IDRRef AS IDRRef
FROM _Document165 T11 WITH(NOLOCK)
WHERE EXISTS(
SELECT 1
FROM _Document165_VT2894 T12 WITH(NOLOCK)
WHERE T11._IDRRef = T12._Document165_IDRRef AND (T12._Fld2896_TYPE = @P2 AND T12._Fld2896_RTRef = @P3 AND T12._Fld2896_RRRef = @P4))
UNION ALL SELECT
P10 AS IDTRef,
T13._IDRRef AS IDRRef
FROM _Document167 T13 WITH(NOLOCK)
WHERE T13._Fld2991RRef = @P4
UNION ALL SELECT
P11 AS IDTRef,
T14._IDRRef AS IDRRef
FROM _Document189 T14 WITH(NOLOCK)
WHERE EXISTS(
SELECT 1
FROM _Document189_VT3843 T15 WITH(NOLOCK)
WHERE T14._IDRRef = T15._Document189_IDRRef AND (T15._Fld3856_TYPE = @P2 AND T15._Fld3856_RTRef = @P3 AND T15._Fld3856_RRRef = @P4))
UNION ALL SELECT
@P3 AS IDTRef,
T16._IDRRef AS IDRRef
FROM _Document171 T16 WITH(NOLOCK)
WHERE T16._Fld3246_TYPE = @P2 AND T16._Fld3246_RTRef = @P3 AND T16._Fld3246_RRRef = @P4
UNION ALL SELECT
P12 AS IDTRef,
T17._IDRRef AS IDRRef
FROM _Document172 T17 WITH(NOLOCK)
WHERE T17._Fld3324_TYPE = @P2 AND T17._Fld3324_RTRef = @P3 AND T17._Fld3324_RRRef = @P4
UNION ALL SELECT
P13 AS IDTRef,
T18._IDRRef AS IDRRef
FROM _Document182 T18 WITH(NOLOCK)
WHERE EXISTS(
SELECT 1
FROM _Document182_VT3660 T19 WITH(NOLOCK)
WHERE T18._IDRRef = T19._Document182_IDRRef AND (T19._Fld3662_TYPE = @P2 AND T19._Fld3662_RTRef = @P3 AND T19._Fld3662_RRRef = @P4))) T1', N'P1 varbinary(4),@P2 varbinary(1),@P3 varbinary(4),@P4 varbinary(16),@P5 varbinary(4),@P6 varbinary(4),@P7 varbinary(4),@P8 varbinary(4),@P9 varbinary(4),P10 varbinary(4),P11 varbinary(4),P12 varbinary(4),P13 varbinary(4)', 0x0000008E, 0x08, 0x000000AB, 0xA3C51CAFF76F613D11E32B207D93C65A, 0x000000BB, 0x00000099, 0x000000A1, 0x000000A4, 0x000000A5, 0x000000A7, 0x000000BD, 0x000000AC, 0x000000B6

т.е. даже не select top 1 where T15._Fld3856_TYPE = @P2 AND T15._Fld3856_RTRef = @P3 AND T15._Fld3856_RRRef = @P4 как я думал...

Мне нравится объяснение (2). Сразу из индекса получают и ссылки, без поиска в основной таблице. Актуально для методов СправочникМенеджер типа Выбрать(),  НайтиПоРеквизиту() .

(13) Это для критерия отбора, я так понял ?

(16) ага. ничего, кроме значения реквизита и ссылки не юзается

Жестко :), особенно когда в критерий отбора реквизит табличной части включен :).

ну и да - при использовании индекса из одной колонки - сам размер индекса меньше пропорционально в n раз

(18) Критерии отбора не так часто используемы.
Выбрали оптимальное решение между
"Долго формируется структура подчинености"
"Долго пишуться документы и раздувается база"

(20) Согласен.

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

(20) про структуру подчиненности что-нибудь слышал когда-нибудь?

(23)+ у нас это один из основных инструментов

(23) Да, слышал.
А какие ко мне вопросы?

(25) ну так вто в том-то и дело, если там будет только реквизит - то не будет ли это эффективнее в принципе (из-за того, что сами индексы в n раз меньше)

(23) Сам же сказал - пихать 2 столбца в индекс ведет к пропорциональному росту.

К чему бы это привело, строй структуру подчинности для типовой, к примеру, где ЗаказПоставщику может быть в ТЧ "Товары" ПТУ. Причем уже составного типа.

(26) А там и так только реквизит.
Мы же счаст про Критерий говорим?

(28) я про стандартную крыжу "индексировать"

(29) и про вариант замены ее на критерий

Счаст добавил индекс реквизиту в ТЧ документа.

1С сделал составной индекс - реквизит+ссылка
Странно.

Я таки за то, что "Индексировать" создает составной инекс еще и с ссылкой с акцентом на более эффективное использование в методах менеджеров, имхо.

"в методах менеджеров"

объясните плиз.

НайтиПоРеквизиту(), Выбрать() с отбором .

Я за то, чтобы делать как можно меньше индексов в
ТЧ, РС подчиненных документам, РН, РБ.

(34) ну это же реально семерочный подход

Выбрать() с отбором не катит. Там весь объект получается.

(35) дык это... зачем тогда в оплатах таб часть со ссылками на другие документы?

(38) Не понял фразу.

(37) кстати да, было такое: v8: Техножурнал и событие LEAKS
если юзать из ссылки - то реально идет много записи на диск и расход оперативы большой

(34) Для этих методов с такими индеком можно все потянуть из самого индекса. из (2) "Чтобы lookup не делать, чтобы получить ссылку из индекса.".
(36) Согласен. Но это надо разработчиков справшивать.

(40)+ http://wstaw.org/m/2013/08/27/0.png

(41) выборка берет все данные, включая ТЧ, НайтиПоРеквизиту - да, ближе

(41) Ради НайтиПоРеквизиту() такое городить?

Надо давно забыть про эти методы, и выпилить их из платформы к херам, забив на обратную совместимость.

А также в модель ССЫЛКА добавить управление объектным кэшем, по умолчанию, отключенным.

(44) ХЗ чеи руководствовались разработчики, я ж говорю ИМХО. Такие же составные индексы они и в семерке делали.
Может на уровне базы проще или быстрее lookup получается по такому индексу.
Это уже слишком глубоко для меня :).

Явно не хватает Odavid в дискуссии, он бы сейчас все разложил по полочкам :))).

просто вот думаю заменить нафиг все "индексировать" на критерии отбора, или нафиг?

(46) http://bbzn.lt/wp-content/uploads/2011/04/visi_moliai.jpg

(47) А ты хитер!

(47) Актуально для документов, ТЧ документов.

Справочники пусть живут.

А вот для регистров - не получиться.

(49) вопрос в том, не будет ли выстрела в ногу от этого (так-то база уже под пол терабайта, индексы похудеют хоть)

(52) Вот и проверим!

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

А разве обычный индекс не всегда содержит кластерный ключ записи?

иначе как от индекса переход к записи происходит

(48) Ну где-то так и разложил бы :).
(52) Че-то глядя на (13) очень похоже на выстрел в ногу :).
Оно конечно, если в критерий из одного объекта только реквизит тянуть, то не так срашно.

(55) Содержит, но если в запросе в выборке только поля, которые есть в индексе, то и переход не делается вообще, из индекса и берет значения.

очень похоже на выстрел в ногу :).


Похоже на выстрел в воздух.

Немного уменьшится база.
Немного увеличиться скорость записи документов.

(57) я не предлагаю получать данные через критерии, я предлагаю через них организовать индексирование

Самый большой и тяжелый объект - страшила РБ в составе 2 штук в УПП. Его никак не замочишь.

(60) Это мы уже поняли.

(55) хотя нет, не так. Индекс хранит номер страницы, а не ключ

(61) и самый тормозной

(58)+ Если я не ошибаюсь, это называется покрывающий индекс применительно к некоторому запросу.

(65) да. вопрос в том, насколько стандартное индексирование (составное) обеспечивает это "покрывание"

(65) Слов то каких понапридумывали...

(66) Вот для методов оно и обеспечивает "покрывание" :).

(68) т.е. никогда не обеспечивает?

(66) если-бы это была киллер фича, то ее давно-бы юзали и заказали-бы у разработчиков платформы такой вид индексирования.

(69) Ну для НайтиПоРеквизиту() должно покрывать, может в отборах в списках как-то помогает, ХЗ. А вообще, ощущение, что по инерции из семерки потянули.
Другого объяснения у меня нету, или не хватает знаний для понимания зачем сделали такие составные индексы для "Индексировать".

(71) ну реально, сколько НайтиПоРеквизиту( в УПП?

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

(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С - надо написать на v8@1c.ru, если это так.

(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) Давай, не томи.

liveups@yandex.ru

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

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

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

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

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

(166) Я о том же.

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

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

(168) Афигеть !

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

Жесть.

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

(169) Тролль!

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