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

[fed]

Цитата:

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

Аксапта, насколько я знаю, так не работает (перебирает неуникальные индексы) по указанной выше причине - всегда есть уникальный индекс и она его использует. В частности да, при выполнении .update() или .delete(), в чём можно убедиться, включив лог операторов SQL.

Или это было о том как теоретически могло бы быть?

А это вообще не на аксаптовском уровне происходит. И даже не на уровне трейсинга SQL-операторов в SQL Profiler. Вот представь себе: У тебя есть таблица персонала. Есть куча индексов, один из которых по полю Пол. Ты говоришь - удалить сотрудника с employeeId=='Иванов И.И.'. Система находит по индексу emplIdIdx физический адрес записи и фетчит ее. Далее - надо удалить из всех индексов ключи, которые на эту запись ссылаются. Система рассчитывает значения индексных ключей (по данным из записи) и пытается найти и удалить все индексные ключи. Для этого она ПЕРЕБИРАЕТ все индексные ключи со значением равным вычисленному до тех пор, пока не наткнется на ключ, ссылающийся на нужную запись (то есть с сохраненным в индексном входе Row_Id==Row_ID нашей записи). Если индекс уникален, то этот перебор не требуется. Если относительно уникален (ну скажем - номер паспорта без серии) - то перебор будет недолгим. А вот если это индекс по полю типа Пол (два возможных значения) - перебор будет медленным и печальным. Собственно - по этому в книжках и не советуют строить индексы по полям с 2-5-10 возможными значениями - обновление такой индекс затормозит, а при выборке редко будет нужен. Но тем не менее - иногда приходится строить индексы по достаточно часто повторяющемуся полю. Даже если на каждое значение будет приходиться порядка 200-300 записей - все равно обновление тормозить будет изрядно.

Насколько я знаю - некоторые БД пытались решить эту проблему за счет того, что индекс подспудно сортировался по сочетанию ключ+физический адрес записи (ROW_ID). (То есть - значение ссылки на запись становилась некой виртуальной частью ключа). Однако - на практике это приводило к изрядным проблемам, поскольку приводило к усиленной перебалансировке дерева страниц при вставке новых записей. Кроме того - при реорганизации и упаковке таблиц, это усложняло перестроение индексов.
Так что - насколько я понимаю, в текущих версиях и SQL Server и Oracle используется именно такой подход к удалению ключей, который я описал...

[ZVV]

petr, fed -- теперь я понял о чём вы, это всё понятно и верно, но непонятно какое отношение к исходному вопросу?

[ZVV]

Цитата:

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

Возможно я что-то путаю, но разве авотматическое добаление RecId в индекс не ограничивается лишь уровенем БД? В смысле меняется ли автоматически индекс и в самом приложении (АОТ)? Если меняется, то в какой момент? при сохранении таблицы? при синхронизации?

не путаете, в Аот - не сохраняет, тем не менее где-то запоминает...
можете попробовать сами: на таблице с индексом по Field1 (неуникальным) в случае .update() на БД уйдёт запрос вида:

UPDATE TABLE2 SET FIELD1=?,RECVERSION=? WHERE ((((DATAAREAID=?) AND (FIELD1=?)) AND (RECID=?)) AND (RECVERSION=?))

Цитата:

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

И ещё возник такой вопрос. Если уникальность RecId контролируется составным индексом, где помимо RecId присутствуют ещё и другие поля, то уникальность отдельно самого поля RecId, вообще говоря, уже не обеспечивается. Не является ли это потенциальным источником ошибок?

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

[S.Kuskov]

Цитата:

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

не путаете, в Аот - не сохраняет, тем не менее где-то запоминает...

Ну раз автоматическое обновление индекса не затрагивает AOT, то тогда ещё раз хочу повторить свой вопрос:

Откуда на SYS слое в AOT уникальне индексы, в составе которых есть поле RecId?

[fed]

Цитата:

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

petr, fed -- теперь я понял о чём вы, это всё понятно и верно, но непонятно какое отношение к исходному вопросу?

Топикстартер спрашивает - зачем создавать индексы с фиктивной уникальностью, добавляя поле recid, если в соответствии с информацией из сообщения Проблема с индексами

система сама добавляет поле recId в первый попавшийся индекс и делает его уникальным ?

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

Ну и гипотеза насчет coverage index тоже весьма правдоподобна.
Таким образом - ручное добавление recId в конец некоторых индексов вызвано не необходимостью отслеживания уникальности, а возможностью повысить производительность работы сервера БД с данным индексом.

[Logger]

Цитата:

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

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

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

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

[S.Kuskov]

Цитата:

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

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

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

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

Цитата:

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

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

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