Привет, всем! В УПП - есть регистр сведений "Версии объектов", измерение "Объект" - составной тип содержит все справочники и все  документы. Необходимо выбрать версии по определенным типам объекта. Я написал следующий запрос..:

ВЫБРАТЬ
    ВерсииОбъектов.Объект,
    ВерсииОбъектов.НомерВерсии,
    ВерсииОбъектов.ВерсияОбъекта,
    ВерсииОбъектов.АвторВерсии,
    ВерсииОбъектов.ДатаВерсии
ИЗ
    РегистрСведений.ВерсииОбъектов КАК ВерсииОбъектов
ГДЕ
    (ВерсииОбъектов.Объект ССЫЛКА Документ.ВводНачальныхОстатковОС
            ИЛИ ВерсииОбъектов.Объект ССЫЛКА Документ.ИзменениеСпособовОтраженияРасходовПоАмортизацииОС
            ИЛИ ВерсииОбъектов.Объект ССЫЛКА Документ.КорректировкаЗаписейРегистров
            ИЛИ ВерсииОбъектов.Объект ССЫЛКА Документ.ПринятиеКУчетуОС)

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

посмотри профайлером, что там на выходе получается. по идее может быть замена на ТИП и/или на Объединить, если кривота.

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

(2) Есть гугл.

(0) А что не так работает?

нормальный запрос, если по полю Объект есть подходящий индекс

(5) Автор может выгружать результат в ТЗ, например, или выводить на экран.

(3) Согласен

(5) индекс-то есть, только он составной из 3-х (в данном случае) полей (на вопрос, почему для составных полей только ссылочных типов не использовать 2 колонки, мне никто не ответил).
вопрос в том, как парсер 1сный делает "ИЛИ" для отбора по первым двум колонкам из трех. может быть банальная штука с заменой ИЛИ на Объединить все поможет в случае, если запрос криво преобразуется. А если не криво - то ничего не поможет.

(5) Я один раз таблицу сформирую в начале функции с помощью запроса, потом по ней с помощью отбора в цикле уже буду находить нужные мне данные.

а смотреть в профайлер мне лень.

(10) Я посмотрю, но думаю, проблема (а ведь мы про нее даже не услышали) - в постобработке

(0)
ВЫБРАТЬ
  ВЫБОР
     КОГДА ВерсииОбъектов.Объект ССЫЛКА Документ.ПринятиеКУчетуОС
     ТОГДА ВЫРАЗИТЬ(ВерсииОбъектов.Объект КАК Документ.ПринятиеКУчетуОС
     КОГДА ВерсииОбъектов.Объект ССЫЛКА Документ..... и т.д.
  КОНЕЦ КАК Док1

(12) мимо

(13) ???

Мы в морской бой играем?

(14) попал!

можно поидее ГДЕ ТИПЗНАЧЕНИЯ(Объект) В (&ТИПЫ)

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

Поддерживаю (12), эта рекомендация еще Рупасова в статье на kb по оптимизации запросов

У тебя проблема не в составном типе а в условии "ИЛИ" - оно не дает индексу в полную силу работать.
Если записей ну очень много - можно сделать запрос из 4 объединений по каждому виду документа

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

(19) ну их же будет меньше

(20) и что?

(17) Он не получает же из документов какую то инфу. Выразить то зачем?

clustered index seek. Расслабьтесь.

(20) технически разницы нет, что 5 типов, что 150. Разница только при обращении к реквизитам, а тут такой задачи нет, и все реверансы эти бессмысленны...

(18) Да кстати, вместо или можно попробовать использовать объединение

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

Именно сервер 1С.

(25) Кхм-кхм. см (23). Курим. Ждем автора.

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

(28) Спс, кэп.

(23) Проверял? Может все-таки scan?

(29) дак ты как будто бы опроверг про "реквизиты", и автор может подумать лишнего)

(30) Проверял. 1С не тупее паровоза.
WHERE ((((T1._Fld24334_TYPE = 0x08 AND T1._Fld24334_RTRef = 0x00000104) OR (T1._Fld24334_TYPE = 0x08 AND T1._Fld24334_RTRef = 0x00000147)) OR (T1._Fld24334_TYPE = 0x08 AND T1._Fld24334_RTRef = 0x0000015F)) OR (T1._Fld24334_TYPE = 0x08 AND T1._Fld24334_RTRef = 0x000001C8))

keyword:

T1._Fld24334_TYPE = 0x08

(25) Разница в том, что у тебя в запросе будет левое соединение с таблицами ВСЕХ типов составного объекта или только те, которые мы явно укажем. А уж обращаемся мы к реквизиту объекта или нет - без разницы

(33) к (24)

(33) откуда там будет соединение-то?

(32) Ты план запроса смотри

+36 а лучше покажи

(33) не будет никаких соединений без залезания "внутрь" составного типа за реквизитом

(35) Хотя вообще, да, из регистра же данные тащим

StmtText                                                                          
Clustered Index Seek(OBJECT:([database].[dbo].[_InfoRg24333].[_InfoR24333_ByDims_RN] AS [T1]), SEEK:([T1].[_Fld24334_TYPE]=0x08 AND [T1].[_Fld24334_RTRef]=0x00000104 OR [T1].[_Fld24334_TYPE]=0x08 AND [T1].[_Fld24334_RTRef]=0x00000147 OR [T1].[_Fld24334_TYPE]=0x08 AND [T1].[_Fld24334_RTRef]=0x0000015F OR [T1].[_Fld24334_TYPE]=0x08 AND [T1].[_Fld24334_RTRef]=0x000001C8) ORDERED FORWARD)

а где вариант с ОБЪЕДИНИТЬ ВСЕ?

(41) Тогда все, в (0) запрос уже оптимален

(41) Ты понимаешь, что индекс здесь используется по признаку Ссылка, а не по признаку Документ.чтото ?

(44) Чего?

(44) Я не понял твоего каммента.

(45) MrStomak просто не в курсе, как хранятся данные в базе 1с и какие там индексы

(47) В курсе
(46) Из твоего поста я понял (32), что используется предикат по полю T1._Fld24334_TYPE в физическом операторе. Это был бы частичный поиск по индексу, так как нужно использование двух полей. Проверил сам - в предикатах поиска присутствует также второе поле.

(48)
Ты очень сложно выражаешь свои мысли. Давай я проще:

1С наложила условие на Класс метаданных (справочник/документ/ПВХ/БизнесПроцесс) и на тип класса метаданных (Документ.ВводОстатков/Документ.РТУ).
И это прекрасно.

Не наложи она условия на Класс метаданных  (_Fld24334_TYPE]=0x08)

индекс бы пошел лесом.

Понапридумывали тут.. (ворчит)

http://www.sql.ru/articles/mssql/2007/012302seekpredicates.shtml

Для следующих ниже примеров, мы можем использовать индекс для удовлетворения условий предиката для столбца "a", но не для столбца "b". В этих случаях потребуется остаточный предикат:

a > 100 and b > 100 a like 'abc%' and b = 2

"потребуется остаточный предикат"
Объясните мне, как это по русски.

indexseek+indexscan?

как это выглядит в профайлере?

Вот так правильно условия:

a > 100 and b > 100

a like 'abc%' and b = 2

(51) В профайлере это выглядит как разделение в тексте плана запроса SEEK и WHERE, но всё это будет index seek

(49) Если преобразовать текст запроса из (0) так:
ВЫБРАТЬ
    ВерсииОбъектов.Объект,
    ВерсииОбъектов.НомерВерсии,
    ВерсииОбъектов.ВерсияОбъекта,
    ВерсииОбъектов.АвторВерсии,
    ВерсииОбъектов.ДатаВерсии
ИЗ
    РегистрСведений.ВерсииОбъектов КАК ВерсииОбъектов
ГДЕ
    (ВерсииОбъектов.Объект ССЫЛКА Документ.ВводНачальныхОстатковОС
            ИЛИ ВерсииОбъектов.Объект ССЫЛКА Документ.ИзменениеСпособовОтраженияРасходовПоАмортизацииОС
            ИЛИ ВерсииОбъектов.Объект ССЫЛКА Документ.КорректировкаЗаписейРегистров
            ИЛИ ВерсииОбъектов.Объект ССЫЛКА Документ.ПринятиеКУчетуОС
            или версииобъектов.объект = значение(Документ.ПринятиеКУчетуОС.ПустаяСсылка))

,то тоже будет Index seek, тоже будут в условии запроса все поля, но при этом будет использоваться только индекс по первому полю TYPE. Я из твоего поста подумал, что именно это и произошло.

(53) Счаст пытаюсь представить себе физический смысл "a > 100 and b > 100" для b дерева и не понимаю проблемы.

(55) Я не понял поста (52) Это к чему?

(56) Я слитно написал их, эти 2 варианта условий в (50), исправился.

(55) Как ты это сделаешь, кроме как сначала выбрав все записи где а>100, а потом, уже из них, где b>100?

(58) Индексное дерево для 2-х полей строится одно?

(58) Или для каждого поля - отдельное дерево. Для полей, в составном индексе.

(60) Как может быть несколько деревьев в индексе? Одно дерево.

Ядро СУБД Cach? использует B+-деревья для хранения данных...
После имени глобала в круглых скобках через запятую
указывается произвольное количество индексов. Компилятор осуществляет
преобразование всего множества индексов в ключ B+-дерева...

Вот.

Тоесть, при выполнении условия "a > 100 and b > 100", это условие должно преобразоваться в условие вида
"key>100"

И потом выполнить типовой поиск по B+ дереву.

Хотя нет.

Ключом B+ дерева тут будет скорее всего Структура с элементами
[a,b]

Или хэш.

Блин.

Нет. Нельзя хэш. Нам нужны исходные данные.

Например, для получения данных через индекс.

Хэш используется для соединений, в индексе мы последовательно сверяем куски известного ключа со значениями для каждой "развилки".

(68) Ты, скорее всего, меня не понял.

(68)

wiki:B-%E4%E5%F0%E5%E2%EE#mediaviewer/Файл:B-tree-definition.png

Что находиться в КЛЮЧЕ корневого узла k1, индексного дерева для полей а, b таблицы, в которой поле a имеет значения от 0 до 100, поле b имеет значение от 100 до 200.

Я вот думаю - там структура со значениями
50,100

Вот ссылка

http://commons.wikimedia.org/wiki/File:B-tree-definition.png#mediaviewer/Файл:B-tree-definition.png

(70) Почему 50,100? Там должна быть конкатенация значений всех ключей.

(70) Точнее, всех полей.

(72) как потом вытаскивать данные, ну, допустим при indexscan?

(72) Как сконкатенировать date и nvarchar?

(74) первые столько-то байт - первое поле, вторые столько-то байт - второе поле

(76) Тупо побайтовый набор? Это и есть Структура.

(77) я думал, у тебя 50,100 означало разные узлы, где значение только а, а не структуру со значениями а и б.

Ну да, так будет узел выглядеть, 50,100

(79) Отлично!

добравшись до узла , где a=100, мы знаем, что всё остальное точно удовлетворяет предикату a>100 и отбираем это. Если мы продолжаем поиск, и находим удовлетворение условию b>100, то это совсем не означает, что все остальные строки удовлетворяют этому условию! Потому что там дальше может быть а=110, б=2, следующая запись а=110 б = 112, потом опять а=111 б = 1. Дальше как ни крути, нужно выполнять скан всех строк индекса.

(81) Стоп. А разве дерево не отсортировано?

Соединяй правым соединение с таблицами этих документов, будет отбор на уровне SQL, отработает быстро.

(82) Отсортировано. Вот тебе порядок - 110 2, 110 112, 111, 1.
Это всё в порядке сортировки побайтовой конкатенации значений полей.

В B-дереве чтобы выполнять поиск по всем полям у нас необходимое условие, чтобы предикаты на все поля, кроме последнего, были на эквивалентность.

(84) таймаут! Пошел думать.

(84) Почему то мне кажется, что сортировка будет не по конкатенации байтов, а по значения полей.

а по значения полей.-> а по значениям полей.

(83) *грустно смотрит*

В корне у нас должны быть серединки диапазонов.

(88) какая разница?

Все. Это для меня слишком сложно. Мне нужно на бумажке начертить дерево и карандашиком поискать по нему.

(89) Пробовал, что бы критиковать? Мб не так причину скорости выполнения написал, но это работает ;)

(90) Ключ один, какие серединки?

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

(94) Ключ один физически, состоит из 2-х частей логически. Я же привел пример со структурой
[50,100]

(92) Не рассматривай а и б как разные ключи. Это один ключ, и он отсортирован.

50 - серединка диапазона [0..100] для поля a
100 - серединка диапазона [0..200] для поля b

(97) Тоесть, в корневом узле, значение ключа не [50,100] ?

(98) нету отдельного диапазона для поля б

(99) Наверху дерева первое значение, то есть 0,100

дальше узлы нормализованно распределяются

(100) При построении индекса - строится побайтовая конкатенация, сортируется, выбирается середина, ее значение записывается в структуру ключа корневого узла?

при этом вторая часть ключа нам бесполезна

(101) Посмотри на схемку http://commons.wikimedia.org/wiki/File:B-tree-definition.png#mediaviewer/Файл:B-tree-definition.png

Там в корневом узле - значение середины диапазона.
И алгоритм поиска - именно по тому, больше или меньше искомое значение значению ключа. В зависимости от этого - идем по нужным потомкам - ветвям.

(105) ты прав, там середина будет.

(106) Фух... Продолжим...
(103) - Это все так?

Ну и середина эта определяется как среденее значение сконкатенированного ключа.

Да

(108) Среднее значение или значение середины диапазона?

(1068) Запись за номером N/2 в отсортированном массиве, где N- число разных ключей.

Даже не разных, есть варианты неуникального индекса наверное.

(111) т.е. Значение середины диапазона. Ок.

(111) Вот теперь все ясно.

Вот теперь понятен смысл последующего indexscan по b>100 после indexseek по a>100

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

Я думал, дерево отсортировано по значениям полей a и b, а не по их побайтовой конкатенации.

(116) Или там у тебя б=100 это начало диапазона.. Такое уже будет от везения зависеть.

(117) Ну так ты спросил вроде бы для этого - одно или несколько деревьев? Нельзя отсортировать один ключ двумя способами.

(119) Точнее, в один момент времени он будет отсортирован только одним образом.

(118) Это очень редкий шанс для больших таблиц.

(119) Я вообще не знал про физику хранения составных индексов.

мне кажется автор темы сейчас очень грустно на нее смотрит) ну и да - закладка.

Для (70) правка

поле b имеет значение от 100 до 200. ->

поле b имеет значение от 0 до 200.

(0) самый лучший вариант оптимизации это не выгребать в запросе поле версия объекта.

(125) Он и не выгребает.

1С не тупее паровоза.

(126) а это тогда кто ВерсииОбъектов.ВерсияОбъекта

(128) Это будет потом, скорее всего, при Хранилище.Получить().

(0) вторая проблема в том, что если это выводится в тз или еще как-то (не через СКД), то система будет делать запрос вида:
SELECT
T1._IDRRef,
T1._Number,
T1._Date_Time
FROM _Document128 T1 WITH(NOLOCK)
WHERE T1._IDRRef = P1

для получения представления для каждой ссылки.

(129) это идет сразу, если через запрос, то сервер 1с все это выгребает и преобразовывает с свои объекты.

(131) Да, ты прав, не заметил это поле в профайлере.

Но как бы, скорее всего, это то и нужно автору.

(133) если идет обработка в цикле версий, то скорее всего это сервисная обработка и вопрос скорости выполнения не стоял. Скорее всего это какой-то отчет или еще что-то.