Ломаю голову не могу понять
Зачем для таблиц rg...
сделан класторный индекс
Период,Измерение_1,Измерение_2,...,Измерение_N

Ведь эти таблицы Очень часто и сильно меняются.
Даже если у Вас месяц ТА совпадает с текущим то все равно
все время идет физическое перестроение этих таблиц и на этом
теряется очень много времени.
Далее существенный выигрыш от кластерного индекса
мы получим только если будем обходить rg таблицу строго в порядке
период,измерение_1,измерение_2,...., измерение_n
а ведь это далеко не всегда соответсвует действительности.

Может кто скажет в чем я прав а в чем ошибаюсь в этих рассуждениях.

kiruha писал(а) 26. Ноября 2008 :: 07:57:

Разве ту же селективность не будет обеспечивать уникальный индекс ?
А что будет с попаданием в индекс для регистра при запросе на ТА ?

Группировка Склад
Группировка Номенклатура

trad писал(а) 26. Ноября 2008 :: 08:18:

Я не делал я думаю почему так сделано.
Какие от этого плюсы и минусы.

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

Z1 писал(а) 26. Ноября 2008 :: 08:05:

1. Порядок группировок не имеет значения
2. Группирование достаточно низкозатратная операция . Может имелся ввиду отбор?
3. Если имелся ввиду "отбор" по  измерениям Склад, Номенклатура, то т.к.
Справочник Фирм маленький (как правило), то появляется реальная возможность задействовать индекс с попаданием в поля
Период,Фирма,Номенклатура,Склад - очень высокая селективность.

4. "эти таблицы rg круто "кобасятся"- ну вообще то т.к. упорядочение начинается с периода, а восстановление
идет от меньшего периода к большему -
то только меняются записи в части таблицы в момент расчета остатков на начало периода.

А при полном перепроведении - только добавляются записи в конец таблицы - быстрее трудно придумать

Ты правда думаешь, что при изменении кластерного индекса записи перемещаются? 

Цитата:
Кен Хендерсон

Кстати, если уж об индексах регистров :

если в rg разработчики очень хорошо продумали индекс,
то в RA (таблица движений) - как будто индекс делал другой человек.

Кажется - возьми да повтори структуру как в rg.
Нет - лепят Цитата:
Кому нужен LINENO_,ACTNO ?
А чтобы провести задним числом приходится все таблицу считывать, да еще и большую часть журнала.
Лечится штатно установкой отбора движений, но в этом случае в отличии от rg -
попадание максимум в 2 поля.

Отсюда тормоза при проведении задним числом.

А по моему наоборот для RA очень хороший индекс так как
IDDOC единственен и селективность самая хорошая супер.

и ситуация следущая при любой реализации в ra может писать
только один кто "владеет" документом,
а в rg  стучаться все даже если у Вас период один = месяц ТА
и при этом нехило колбасят либо саму rg либо ее кластерный индекс.

berezdetsky писал(а) 26. Ноября 2008 :: 12:04:

И да и нет.
В ra мы записали и забыли, а в rg еще надо сделать +.
причем в ra iddoc единственен ( первое поле ключа а ведь по нему идет основная селективность)
а записей в периоде rg   поле PERIOD очень много.
Также в ra длина записи может быть намного больше длины ключа
а в rg  длина записи практически совпадает с длиной ключа.

kiruha писал(а) 26. Ноября 2008 :: 12:37:

Остаток на какую дату?
и вообще если Вы перепроводите сегодня 26.11.2008 документ за 01.02.2008 год еще очень и очень большой вопрос нужно или нет считать этот остаток.
Опять же при проведении переколбашивание индекса не зависит считаете Вы или нет остаток в модуле проведения.
в периоде много записей  Бутылка может оказаться и последним товаром  в текущем периоде.

kiruha писал(а) 26. Ноября 2008 :: 12:57:

ах вот Вы о чем ну от этого никуда не деться и придеться пересчитать по ra c 01.11 по 15.11 простым сканированием соеденившись с jornl( поэтому 1с и рекомендует брать остатки на ta)
и мое утверждение не протеворечит Вашему если Вам надо считать
очень и очень часто остатки в середине месяца то нужен индекс
товар ... Также сначала нужно получить
значение остатка этой бутылки на 01.11 а для этого надо найти ее
сначала в rg а  на это  тоже нужно время найтись.

Z1 писал(а) 26. Ноября 2008 :: 13:48:



Цитата:

См Телега о кластерном индексе

Цитата:

У обычного индекса на уровне листьев находится ключ индекса и row id данных, а у кластерного там непосредственно данные. Только и всего..

Z1 писал(а) 26. Ноября 2008 :: 14:54:

Там сказано только то, что сказано. Не надо приписывать мне свои мысли. В кластерном индексе данные смешаны с индексом - по-этому он и называется "кластерный".

А для чего еще нужен индекс в таблице движений регистра -
чтобы либо быстро рассчитывать остатки, либо быстро смотреть движения в отчетах.
И то и другое родной индекс 1С (в RA) делает плохо.

Разумно в регистрах ставить "отбор движений" по Номенклатуре и Контрагент(или соответственно Договор)
По умолчанию в 1С этих отборов нет - видимо ориентация на мелкие фирмы.

kiruha писал(а) 26. Ноября 2008 :: 15:54:

не только. Может исходили из того т что выбрать остатки только из
rg гораздо лучше и быстрее чем из двух таблиц rg и ra.
а если строиться матерьяльная ведомость то все равно сканируется весь ra по датам.

kiruha писал(а) 26. Ноября 2008 :: 15:54:

а можно это утверждение развернуть тезисно.

kiruha писал(а) 26. Ноября 2008 :: 15:54:

посмотрел но ведь в регистре остатоков есть
а - быстрая обработка движений добавляет datetime_id_doc в индекс вместо iddoc
б - отбор движений вот он то и создает индекс по измерению
или по реквизиту регистра
индекс равен = ( измерение,кластер индекс )

также можно создать дополнительный индекс и по rg итоги
индекс = период, измерение.

Я придумал ведь еще можно по измерению регистра создать индекс
как "графа отбора 1с" можно посмотреть что он при этом понасоздает - для моих задач это точно не нужно



Так что получается с индексами для регистра внутри 1с все в порядке создавай обдуманно какие тебе нужны

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

spock писал(а) 27. Ноября 2008 :: 05:46:

Добавлю от себя, что уважаемому Z1 неплохо бы ознакомиться с
http://www.sql.ru/articles/mssql/03013101Indexes.shtml
а также просмотреть форум на SQL.RU на предмет
http://www.sql.ru/forum/actualtopics.aspx?search=%EA%EB%E0%F1%F2%E5%F0%ED%FB%E9+...
И очень хотелось бы не просто теоретических обоснований, а с приведением планов запросов, DURATION запросов и их COST из планов.

Z1 писал(а) 27. Ноября 2008 :: 05:41:


Да я имел ввиду простую вещь.
По умолчанию в типовых в RA стоит только один индекс iddoc + lineno_ + actno (I).
И что этого индекса не достаточно.

Индекс
Товар + date_time_iddoc + lineno_ + actno (III)
нужно добавлять правкой конфигурации, о чем и писал :
kiruha писал(а) 26. Ноября 2008 :: 15:54:


Извиняюсь, если писал достаточно непонятно.

и еще вопрос предположим что у нас есть регистр
остатки с такой структурой
Фирма,Номенклатура,Склад и если нам надо очень  быстро получать остатки Номенклатура,Склад на произвольную дату
текущего месяца то самый быстрsй для этого индекс будет
по таблице Ra
Товар,Склад,Date_Time_IDDOC desc

просто в статье сказано что составной индекс быстее чем
несколько отдельных индекса.
или я все равно где=то ошибаюсь ?

Z1 писал(а) 28. Ноября 2008 :: 06:07:

Я без личного наезда, твоей пользы для: а понял ли ты почему композитный индекс (покрывающий/covered) лучше нескольких отдельных?

ps: Я подсказки дал в скобках для поиска, если не найдешь, думаю, нам не проблемно будет пояснить.

Z1 писал(а) 28. Ноября 2008 :: 16:57:

Видимо, все-таки нужно поговорить на эту тему
Вот для примера ситуация:
- имеем таблицу с полями Склад, Фирма, Товар. Нужно определиться каким образом организовать индекс(ы) и его(их) тип.
Часто видел ситуацию, когда народ расставляет поля в индексе в порядке: Фирма + Склад + Товар (в случае регистра и измерений, соответственно). С одной стороны есть логика: вдруг нужно будет будет получать остатки по Фирме, а иной раз даже еще и по Складу. В большинстве случаев количество Фирм и Складов значительно меньше количества Товарных позиций.

На наборе данных (Фирма - Склад - Товар) с фильтром по Фирма1 + Склад1:
Фирма1 - Склад1 - Товар1
Фирма1 - Склад1 - Товар2
Фирма1 - Склад1 - Товар3
...
Фирма1 - Склад1 - ТоварN
Фирма1 - Склад2 - Товар1
Фирма1 - Склад2 - Товар2
Фирма1 - Склад2 - Товар3
...
Фирма1 - Склад2 - ТоварN
...

поведение ms-sql сервера будет таким:
Оптимизатор видит, что индекс такой Фирма + Склад + Товар, а условие выборки такое Фирма + Склад и строит план, скорее всего, Index Seek. Т.е. наше условие накладывается на индекс полностью. В служебных табличках сервер хранит плотность/распределенность (Statistics) данных в индексе и соответственно знает с какого места(!) нужно начинать перебор индекса (тут, вообще-то, помогает структура хранения индекса - B-tree и IAM). Мы получаем данные просто пройдя индекс и, взяв данные из самого индекса (для случая некластерного индекса).

Как мы знаем, в некластерном индексе организована определенная структура хранения. На листьях (leaf nodes) дерева хранятся данные индекса (т.е. это данные тех полей, которые указаны в индексе, в соответствии со способом сортировки), если же этих данных для выборки недостаточно, то серверу нужно будет спуститься по логической структуре дерева до самих данных (data leaf), которые храняться в куче (heap) через идентификатор (row locator). И если с B-tree все ясно, там поиск нужных значений производится крайне быстро, то в куче мы попадаем в "кучу". Т.е. тут нужно проводить тупой перебор (для начала пройтись по дереву по индексу, а чего нехватает - перебором кучи) - это очень злые Закладки (Bookmarks), довольно-таки тяжелая операция.

А вот теперь меняем изначальные условия:
- набор данных тот же;
- индекс Товар + Склад + Фирма; <<<<-- индекс поменяли
- условие отбора Фирма1 + Склад1 + Товар1

Вот тут на сцену выплывает такое понятие как 'селективность' (selectivity). Вроде термин простой, но объяснить не просто
Например, если в таблице 100 строк и все они уникальны (или почти все), то селективность данных высокая. И наоборот, если  таблице 100 строк и почти все они одинаковые, то селективнолсть низкая (или в виде формулы: X = КоличествоСтрокУдовлетворяющихУсловиюОтбора / КоличествоСтрокВообще, где X ->> 0 - ВысокаяСелективность ).

Теперь коротко о случае, если бы для каждого поля был бы свой индекс:
IX_I(Фирма)
IX_II(Склад)
IX_III(Товар)
многие делают именно такие индексы, и считают, что этого достаточно - бог им судья Есть мнение, что от таких индексов оптимизатору сносит мозг. Он отдельно отбирает по Фирме, отдельно по Складу, отдельно по Товару строки соответствующие критерию отбора, а потом делает сливание этих данных. Для условия Фирма1 + Склад1 + Товар1 и начального набора данных получаем скорее всего такую картину (... не считаем):
1. отбор по Фирма1 = 8 строк;
2. отбор по Склад1 = 4 строки;
3. отбор по Товар1 = 2 строки;
4. а теперь по внутренним индентификаторам сделаем сливание и выбор общих (merge)

А может даже, что будет Scan, не ясно что хужее.

ps: сойдет для пояснения??

JohnyDeath писал(а) 28. Ноября 2008 :: 20:53:

Если есть индекс Товар + Склад + Фирма и необходимо получить данные по по конкретному складу определенной фирмы, то в индекс мы не попадаем. Первым полем у нас идет Товар, а условия накладываются по складу и фирме, следовательно, чтобы серверу получить то, что ты просишь, ему нужно будет просканировать индекс.
Но в примере был акцент на том, что в условиях отбора появился товар. Т.е. нужны остатки по конкретной фирме, конкретному складу и конкретному товару. Лично мне кажется, что в oltp-базе, в которой постоянно проводят расходные накладные, перемещения и прочие документы, которым для проведения нужно получить итоги как раз по такому условию (фирма+склад+товар), будет самым лучшим. В смысле, получение итогов более критичная к скорости, чем просто отчет по остаткам.
Ну и еще есть такое правило для выбора расстановки полей в индексе:
СелективностьПоПолю1 > СелективностьПоПолю2 > СелективностьПоПолю3 > ... > СелективностьПоПолюN

SELECT
    COUNT(*) as ОбщееКоличествоСтрок,
    COUNT(DISTINCT field1) as КоличествоУникальныхСтрокДляПоля1,
    COUNT(DISTINCT field2) as КоличествоУникальныхСтрокДляПоля2
FROM table
 

я конечно не разбираюсь сам так хорошо в ms sql
но думаю так
Без индексов плохо.
Когда индексов много и они "протеворечивы" оптимизатору запросов крышу сносит sql бы уже все простым scanом сделал
а оптимизатор все думает какой индекс все таки для этого
надо использовать ( при этом переберая горы статистики)

сам по себе индекс никому не нужен. индекс должен решать
конкретную Задачу ( главную)
Вон у меня главная задача толучение итогов на ТА а
у kiruha главная задача получение остатков на любую
дату.
и глядя на один и тот же регистр и его индексы я говорю все классно все работает и индексы хорошие.
kiruha - все очень медленно  не могу я так вычислять
остаток бутылки на 15 число.
Кто из нас прав. Да оба мы правы только каждый по своему.
Исходя из этого spock все твои высказывания я плохо понимаю
ну во первых не хватает квалификации во вторых не знаю какую главную задачу ты решаешь.

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