Зачем нужен уникальный index, содержащий RecId?

[ZVV]

Цитата:

Сообщение от fed

Ну bitmap индексы хороши в тех случаях когда у тебя совсем мало возможных значений у индексного поля - в пределах 10-20. А вот в ситуации когда у тебя в таблице миллион записей и тысяча возможных значений - bitmap слишком тяжел, а обычный b-tree индекс не уникальный слишком тормозит.

У битмап-индексов есть к тому же ещё ограничения касательно блокировок. Не помню уже точно подробностей, но суть в том, что при изменении поля в таблице, в битовом индексе блокируется не только эта строка, но и часть других, что связано с перестройкой битовой "карты".
В связи с этим данные индексы обыно не рекомендуется использовать в OLTP системах с интенсивным обновлением данных. Обычно они находят своё применение в хранилищах данных.

[mazzy]

Цитата:

Сообщение от S.Kuskov

Отсюда вопрос. Какой смысл вручную создавать такой абсурдный с точки зрения приложения индекс (уникальность RecId - это всё же забота ядра и БД). И не в этом ли кроются ошибки, такие как Существуют аргументы, почему неуникальность баркода у номенклатуры не является багой?

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

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

[lev]

Цитата:

Сообщение от ZVV

Редко такое встречали говорите... ))))
Было бы интересно взглянуть хоть на одного...

Включение потабличного RecID в 3-ке

Редко встречал = Не видел ни одного )))))))))))))

[S.Kuskov]

Подниму давнишнюю тему уникальных индексов ещё одним "Почему?"

Для чего таблице ProdJournalBOM несколько уникальных индексов, "перекрывающих" друг-друга? Я понимаю, когда разными уникальными индексами контролируют уникальность разных наборов полей. Но для чего может понадобиться ставить свойство уникальности на соседние индексы, которые помимо новых полей содержит в себе абсолютно все поля из первого уже уникального индекса? Или это банальная опечатка и на это можно не обращать внимание?

[AndyD]

Если посмотреть в трешку, то там LineIdx неуникальный (в AOT, в базе он уникальный, но за счет добавления RecId)

Скорее всего, в DAX2009 (или уже в четверке?) просто сделали этот индекс уникальным, а два других (VoucherIdx и TransIdIdx) трогать не стали

[oip]

Цитата:

Сообщение от AndyD

Если посмотреть в трешку, то там LineIdx неуникальный (в AOT, в базе он уникальный, но за счет добавления RecId)

В некоторых версиях он уникальный и в тройке.

[AndyD]

Странно.

Слой sys, изменения от 2002-го года - уникальность не включена
Есть еще слой syp, изменения от 2005-го года - уникальность не включена

Это я про свою версию, из подписи

[fed]

Ладно, я тут еще немножко теории добавлю:
Во первых - уникальный индекс всегда чуть меньше нагружает SQL Server чем не уникальный:
1. Не надо хранить гистограмму в статистике индекса, поскольку заведомо известно что по данному условию (скажем - inventTransId+journalid+lineId) всегда найдется только одна запись.
2. Уникальные индексы чуть быстрее обновляются, поскольку, опять таки, при удалении/обновлении записи не надо перебирать n-индексных входов в поисках того, который надо удалить.
Во вторых - начиная с DAX2009, система поддерживает кэширование по нескольким уникальным ключам. То есть, в памяти храниться кэш записей и отдельно болтается НЕСКОЛЬКО B-Tree (а может и хэшей - не знаю), в которых хранятся значения разных уникальных ключей. Так что работа с уникальными индексами позволяет экономить ресурсы не только сервера БД, но и сервера AOS.(NB - в 4ке и более ранних версиях, кэширование работало только для индекса, указанного как primary index таблицы).
В третьих, хочу напомнить что индексы используются не только для поиска, но и для сортировки. И если запрос не очень сложный, а индекс подходящий, то order by/group by может быть выполнено без дополнительных сортировок, за счет использования готового индекса. (Хотя это явно не случай ProdJournalBOM).
Ну и наконец хочу напомнить о таком понятии, как покрывающий индекс. Если все поля в запросе, находятся в неком индексе, система может выполнить запрос без необходимости чтения из таблицы. Например запрос select journalId from prodBOMJournal where prodBOMJournal.inventTransId==_inventTransId будет выполнен с помощью одиночного поиска по индексу transIdIdx, без чтения данных из таблицы.

[AndyD]

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

И не совсем понятно, почему не нужна гистограмма (и почему ее нет)?
Индекс ведь составной и, соответственно, кол-во записей для, к примеру, prodBOMJournal.JournalId, больше единицы (а если еще про dataAreaId вспомнить...)

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

NB Если имелось в виду, что добавляем RecId к неуникальному индексу и ТОГДА обновление будет идти быстрее, за счет того, что не надо будет обрабатывать все неуникальные вхождения ключа, то согласен Но, опять же, и без включения уникальности такой подход будет работать быстрее

[fed]

Цитата:

Сообщение от AndyD

И не совсем понятно, почему не нужна гистограмма (и почему ее нет)?
Индекс ведь составной и, соответственно, кол-во записей для, к примеру, prodBOMJournal.JournalId, больше единицы (а если еще про dataAreaId вспомнить...)

Ну - если индекс помечен как уникальный, то запрос по всем полям в индексе однозначно вернет одну запись. Соответственно - данные о распределении хранить не надо. А вообще - гистограммы в SQL Server для меня загадочная штука. Где-то написано что они хранят только распределение ПЕРВОГО поля в индексе. Хотя на практике, первое поле в Аксапте это почти всегда dataareaid. И гистограма не должна содержать больше входов чем у тебя компаний в БД. А она содержит
Так что возможно я здесь и неправ.
Во вторых, если читать дискуссию с начала, то речь идет не только о признаке уникальности индекса, но и вообще о том как правильно подбирать ключи индекса и по каким принципам поля в индекс включают. Вот я и решил некие вещи напомнить.

А вообще по проблеме конкретной таблицы prodJournalBOM, я думаю там расставили признаки уникальности только для кэширования. Более того, могу предположить что разработчикам просто тупо спустили метрику "Сконвертировать n индексов из неуникальные в уникальные" - Типа из общих соображений, как в 2012ой все отнормализовали из общих соображений. Вот они и сконвертировали

[AndyD]

Увидеть статистику не просто, а очень просто DBCC SHOW_STATISTICS Или в разделе Статистика для таблицы в Management Studio (собственно, там выводится результат выполнения команды)

Там же (по ссылке) написано и про первый столбец для гистограммы

[fed]

Цитата:

Сообщение от AndyD

Увидеть статистику не просто, а очень просто DBCC SHOW_STATISTICS Или в разделе Статистика для таблицы в Management Studio (собственно, там выводится результат выполнения команды)

Там же (по ссылке) написано и про первый столбец для гистограммы

Несколько отвлекаясь от темы, хочу заметить что я из за этого первого столбца иногда строю статистику в ручную, задавая условия фильтрации. То есть - если у меня в БД есть две больших компаний и несколько маленьких, я ручками строю две статистики по некоторым полям, задавая условия фильтрации dataareaid='co1' и dataareaid='co2' соответственно. Как-то мне показалось что сиквел в таких условиях реже промахивается с планом запроса.

[Logger]

Цитата:

Сообщение от fed

[LEFT]...Для повышения производительности полезно добавлять уникальное поле во все индексы с малой селективностью, а не только в первый попавшийся...

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

Кроме того, если бы это было так, то почему же тогда на всех индексах не включают уникальность добавлением в конец столбца recId ?
Мне кажется что если рассматривать упомянутые таблички, в которых удаление записей и обновление ключевых для индексов полей бывает редко, то для них главным критерием построения индексов является не их обновление, а быстрый доступ и сканирование. И там наличие лишнего поля в ключе может ухудшить производительность.

[Logger]

Цитата:

Сообщение от fed

Несколько отвлекаясь от темы, хочу заметить что я из за этого первого столбца иногда строю статистику в ручную, задавая условия фильтрации. То есть - если у меня в БД есть две больших компаний и несколько маленьких, я ручками строю две статистики по некоторым полям, задавая условия фильтрации dataareaid='co1' и dataareaid='co2' соответственно. Как-то мне показалось что сиквел в таких условиях реже промахивается с планом запроса.

Это наверно из-за того что в индексируемых полях значения как правило генерятся из номерных серий, значения в который монотонно возрастают в пределах одной компании. Конечно есть и исключения, когда несколько номерных серий пишут в один столбец. Но мы же их как правило мастером настраиваем и они имеют поэтому одинаковый префикс равный коду компании.
Т.е. гистограммы в вашем случае должны точнее описывать распределение данных. Поэтому и оптимизатор лучше работает.

[Logger]

Также при работе с уникальным индексом должны быть накладные расходы на собственно проверку и поддержку уникальности. Разве нет ?
Или потери на это незначительны ?

[AndyD]

Цитата:

Сообщение от Logger

Также при работе с уникальным индексом должны быть накладные расходы на собственно проверку и поддержку уникальности. Разве нет ?
Или потери на это незначительны ?

По сравнению с чем?

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

Если же говорить о добавлении нового индекса - то тут к гадалке не ходи. Дополнительные накладные расходы при изменении появятся однозначно

[Logger]

Цитата:

Сообщение от AndyD

По сравнению с чем?

Имел в виду - уникальный индекс по сравнению с таким же по составу полей, но объявленному как неуникальный.

Хотя применительно к recid это не имеет значения, так как любой индекс содержащий recid при синхронизации в БД создается как уникальный.

Ну, просто интересно разобраться. Предположим для случаев когда recid не входит.

[AndyD]

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

[AndyD]

Цитата:

Сообщение от Logger

Это наверно из-за того что в индексируемых полях значения как правило генерятся из номерных серий, значения в который монотонно возрастают в пределах одной компании. Конечно есть и исключения, когда несколько номерных серий пишут в один столбец. Но мы же их как правило мастером настраиваем и они имеют поэтому одинаковый префикс равный коду компании.
Т.е. гистограммы в вашем случае должны точнее описывать распределение данных. Поэтому и оптимизатор лучше работает.

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

[S.Kuskov]

Цитата:

Сообщение от AndyD

По сравнению с чем?

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

Получается что от уникальности индекса только одна польза причём без каких-либо затрат?

Цитата:

Сообщение от Logger

если бы это было так, то почему же тогда на всех индексах не включают уникальность добавлением в конец столбца recId?

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