Ну вот есть древовидный индекс в базе

Вот мы нашли вхождение на первом уровне, вот на втором, на третьем и так дошли до конца индекса (B-дерева).

А как мы найдем запись в таблице, найдя конец этого самого В-дерева?

(0) Вопрос полегче: могут ли выполнять функцию индекса такие структуры как массивы и списки? (допустим БД висит в оперативной памяти целиком). Ответ обоснуйте.

Пусть людям будет пища для размышлений.

(1) таблицу значений в 1С можно проиндексировать)

вопрос в (0) - мне нужен на него ответ. я тут не устраиваю спец. олимпиаду

(0) чего в деревянном индексе ищешь?

(0)Листьями дерева как раз и являются записи.

(4) да, листьями.

Но запись надо еще найти. Где связь между этой иерархической структурой и таблицей СУБД?

У нас снова появляется поиск - дерево (найденный индекс) и таблица? WTF?

(5) Упрощенно:в листке дерва записано "Запись номер 324584357". Дальше движок в таблице запись быстро находит по порядковому номеру

(6) т.е. индекс для нескольких полей только создается, правильно?

Соответственно мы находим индекс (поиск по нескольким полям) и уже дальше по номеру записи прыгаем туда, куда надо?

(7) Да, как оглавление в книге

(8) спасибо, это то, что я хотел узнать

Чтобы не плодить темы, спрошу здесь.

Создал 2 измерения в регистре накопления, у обоих отметил галку "Индексировать".

Ожидал появление индекса, в поля которого войдут оба измерения, однако, этого не произошло - в СУБД (MS SQL) появилось 2 индекса.

Вопрос, а как же нам тогда создать индекс по обоим измерениям, допустим, я хочу искать сразу по складу и номенклатуре, или я чего-то не понимаю?

(10) Никак.
1с не создаёт составные индексы по произвольным измерениям.
Руками сделай.

(11) WTF??? O_O

(12) Чо? (с)

(11) а потом при реструктуризации снова их делать?

(14) И чего? Сделай...

Составной индекс возможен только когда мы в запросе создаем временную таблицу и индексируем несколько полей?

(16) под составным я подразумеваю состоящим из пользовательских полей

(16) Да.

(16) Но этого делать не надо почти никогда.

(19) это в принципе понятно.

Заглянул в регистр накопления "ПартииТоваровНаСкладах" - там проиндексировано поле "Склад", но не проиндексировано поле "Номенклатура".

Они там что, измерением ошиблись, когда галку ставили, или это имеет какой-то смысл?

(20) УПП*

(20) А что не так?

Номенклатуру они отбирают сразу с Периодом, работает Кластерный индекс.
Склад они отбирают вместе с Номенклатурой - работает кластерный индекс, либо без Номенклатуры - работает индекс по Складу.

(20) Кстати, Перенеси Измерение "Организация" на самый верх, походу добавляли его в каком-то релизе, забили (забыли) про индексы.

(22) а откуда кластерный индекс знает, что поле "Номенклатура" будет в него включено?

(22) ну например в том же регистре "ПартииТоваровНаСкладахБухгалтерскийУчет" индексация наоборот - номенклатура проиндексирована, а склад нет.

Это зависит от дальнейшего использования регистра (написанных запросов, получающих из него данные)?

(24) В кластерный индекс таблицы остатков включен:
Период
Все измерения регистра
Разделитель

(25) Там первым идет Организация, из за этого (но я поспорю с этим решением).

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

(26) у меня в кластерном индексе нет измерений

http://i65.fastpic.ru/big/2014/1027/46/8480b9b1cebe6f57d0a7a01c5266e546.png

(28) При Партионном списании всегда стоит фильтр по Организации (а это главное).

(29) Это таблица движений

(31) Точно. Нашел! :)

(31) спасибо

-----Продолжаю вопросы-----

Вот смотрите, kb.1c.ru говорит, что у таблицы документа всегда есть кластерный индекс по Ссылке (GUID)

Вроде как GUID формируется - первые 8 байт это дата компьютера + что-то еще, вторые 8 байт - железо

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

WTF?

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

(34) у тебя положение документа на временной оси чем определяется? наверно не GUID-ом, верно?

http://forum.sources.ru/index.php?showtopic=101231

ух ты, я оказывается не один такой

(36) у нас есть таблица, по которой создан кластерный индекс. Согласно определению кластерного индекса, в этом случае физическая таблица сортируется по связанной с индексом колонке, в данном случае по ссылке (GUID).

В вопросе я конкретно про физическую таблицу

(38) На физическом уровне таблиц не существует. Уймись уже.

(39) Хренассе... О_о

(39) вот это поворот

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

(42) я сейчас читаю главу 8, Вильямс - Программирование баз данных MS SQL 2005

на физическом уровне там же страницы, смещение, не?

набрел на ветку

v8: Установка момента времени документа

(44) я про физический уровень, на котором я вижу таблицу в MS SQL Management Studio

(44) там HoBT
(46) И что, ты сам что ли будешь записи искать? Искать их будет движок СУБД, и оперировать он будет не таблицами.

(47) вопрос в (34) и он до сих пор не разрешился

(48) тебе какая разница?

(49) задача стоит

(50) Прими холодный душ.

(51) в тренажерку схожу и приму, хватит оффтопить

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

(53) можно еще подробнее, ссылку на ресурс 1С или еще что-то такое? Откуда инфа?

(53) http://devtrainingforum.v8.1c.ru/forum/thread.jsp?id=603489&print=0

набрел на веточку

(52) Хватит страдать херней. Ты полез в дебри которые для решения задачи не нужны. Между тобой и данными - N слоев абстракций, предоставляемых различными компонентами большой информационной системы. Чего ты лезешь на финальный? Почему начинаешь с конца? Приведи задачу - тебе помогут, нафига вот это теоретизирование о высоких материях?

:) "..больше знать не надо, но это надо знать на зубок" (С) Карты, деньги, два ствола

(56) все гораздо прозаичней

(34) 1С генерирует гуиды для ссылок "читерски". Если сделать

Для Шаг = 0 По 10 Цикл
   Сообщить(Справочники.Справочник1.ПолучитьСсылку().УникальныйИдентификатор());

КонецЦикла;

- то можно увидеть, что в них некоторая часть последовательно возрастает.

Насколько помню обсуждение на партнерке - это именно борьба с page splits.

В ветке
v8: Где взять описание GUID, который в 1С 8?

H A D G E H O G s

ответил на вопрос в п.7

Всем спасибо, все свободны.

Кстати, товарищ в
https://partners.v8.1c.ru/forum/topic/620414#m_620414

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

(61)

https://partners.v8.1c.ru/forum/topic/620414#m_620414

(34) подтвердил мысль практически.

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

Положение документа в списке будет зависеть от того, какой был начальный ГУИД сеанса для данного типа документов. Т.е. в списке будут по порядку идти сначала либо документы 1го клиента, либо документы 2го клиента.

Вот такая практическая закономерность.

Добавлю свои 5 копеек про индексы.
Для каждого нового объекта метаданных система автоматически создает основной кластерный индекс. Он один для каждого объекта. Для периодического РС он выглядит так: Период + Измерение1 + Измерение2 + ... Как видите, индексировать первое измерение  нет смысла, тк в основном индексе уже измерение1 идет впереди. Если включить индексирование у второго измерения, то будет создан новый индекс: Измерение2 + Период + Измерение1 + Измерение2 + ... Аналогично и с реквизитом или ресурсом.

(64) что-то у тебя тут запутанно как-то

на kb.1c.ru отдельная статья есть про создаваемые индексы

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

у меня все-таки выполняется CLUSTERED INDEX SCAN,
а не INDEX SEEK?

(66) да и не факт, что виновата именно "составность" индекса

(67) Селективность, не?

(68) т.е. оптимизатор принял решение, что тот вариант будет лучше?

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

Если я выполняю запрос для нескольких полей выборки с условием WHERE по этой таблице по проиндексированному полю (которое по порядку является первым в составном индексе), выборка должна идти через INDEX SEEK.

Как тут оптимизатор запроса мог принять стратегию INDEX SCAN?

Причем INDEX SEEK выполняется, если в запросе идет выборка по одному полю - проиндексированному.

(70) Странно.

(70) А Index scan по тому же индексу ? Может сканировался другой индекс, где есть все поля выборки.

(72) Сканировался кластерный индекс, дефакто - таблица.

Как догадаюсь, почему так, отпишусь

(70) какой процент записей таблицы вы получаете этим запросом? ЕМНИП, если ожидается, что запрос вернёт более 10% записей таблицы, SQL Server не заморачивается на index seek.
Возможно, статистика устарела и сервер обманывается.

Хотя, с учётом (66), скорее всего, количество записей и размеры индексов таковы, что оптимизатор решает, что быстрее будет один раз просканировать кластерный индекс, чем сначала лезть в некластреный индекс, а потом в кластерный за доп. полями.

(75) "чем сначала лезть в некластреный индекс, а потом в кластерный за доп. полями."

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

(76) в (70):
>>Просто я думал: есть таблица, есть по ней составной не кластерный индекс.

(76) Как раз-то у ТС некластерный индекс.

" есть по ней составной не кластерный индекс"

(78) (77) Балин, кривые мои глаза.

Индекс недостаточно селективен, чтобы делать indexseek+keylookup в случае наличия доп. полей, но достаточно селективен, чтобы сделать indexseek вместо indexscan по одному полю, вот и все дела.