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

[lev]

Цитата:

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

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

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

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

[mazzy]

Цитата:

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

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

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

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

[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

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

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

[AndyD]

Цитата:

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

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

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

[fed]

Цитата:

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

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

Возможно сильно разное распределение ключей по компаниям. Например у нас одна компания очень активно используется для сводного, и в ней в reqTrans полмиллиона записей, принадлежащих 7 разным планам. Из оставшихся компаний, парочка имеет только по одному плану и еще штук шесть просто не используются для сводного. Поэтому в зависимости от компании, условие dataareaid==_dataareaid && reqPlanId==_reqplanId обладают разной селективностью. Подозреваю что если у тебя есть статистика по reqPlanId без условия по коду компании, то отимизатор будет чаще промахиваться и выбирать некорректный план. (Скажем - выборку по коду плана, для тех компаний в которых он только один)...

[Logger]

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

[AndyD]

Цитата:

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

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

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

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

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

[Logger]

Цитата:

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

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

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

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

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

[AndyD]

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

[mazzy]

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

[AndyD]

Цитата:

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

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

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

Как-то у вас все смешалось

Я говорил, что для СУЩЕСТВУЮЩЕГО индекса включение уникальности ничего не добавляет в плане ухудшения производительности.

Если речь идет о добавлении ДОПОЛНИТЕЛЬНОГО (дополнительных) столбца для обеспечения более высокой скорости вставки/изменения, то надо рассматривать два варианта.

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

Второй - у таблицы нет кластерного индекса. Соответственно, все индесные записи ссылаются на файл с данными, номер страницы в нем и номер записи в странице (все это представляется в виде 64-х битного поля), так называемый Heap RID. Так вот, этот самый Heap RID выступает в этом случае, как еще одно индексное поле, данные отсортированы в том числе и по нему. Т.е. если мы вставляем или изменяем записи в таблице, поиск по индексу идет в том числе и по Heap RID. И добывление полей, так же будет вести к увеличению размера хранимых данных


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

Да, еще добавлю.
Я пишу про MS SQL (по крайней мере, от 2005-го). Для Oracle, возможно, соображения будут другие