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