|
|
11.07.2011, 15:55
|
#1 |
|
Участник
|
Любой индекс является покрывающим (если запрос по полям, входящим в него, естественно).
К уникальности индекса это не имеет отношения, так что, последний пункт отпадает  И не совсем понятно, почему не нужна гистограмма (и почему ее нет )? Индекс ведь составной и, соответственно, кол-во записей для, к примеру, prodBOMJournal.JournalId, больше единицы (а если еще про dataAreaId вспомнить...) Насчет того, что будет обновляться быстрее - если в обычном индексе будет по одному вхождению на каждый ключ, то скорость будет такая же, как и для уникального индекса NB Если имелось в виду, что добавляем RecId к неуникальному индексу и ТОГДА обновление будет идти быстрее, за счет того, что не надо будет обрабатывать все неуникальные вхождения ключа, то согласен Но, опять же, и без включения уникальности такой подход будет работать быстрее
__________________
Axapta v.3.0 sp5 kr2 Последний раз редактировалось AndyD; 11.07.2011 в 16:11. |
|
|
|
11.07.2011, 16:22
|
#2 |
|
Moderator
|
Цитата:
Сообщение от AndyD
И не совсем понятно, почему не нужна гистограмма (и почему ее нет
)? Индекс ведь составной и, соответственно, кол-во записей для, к примеру, prodBOMJournal.JournalId, больше единицы (а если еще про dataAreaId вспомнить...)  Так что возможно я здесь и неправ. Во вторых, если читать дискуссию с начала, то речь идет не только о признаке уникальности индекса, но и вообще о том как правильно подбирать ключи индекса и по каким принципам поля в индекс включают. Вот я и решил некие вещи напомнить. А вообще по проблеме конкретной таблицы prodJournalBOM, я думаю там расставили признаки уникальности только для кэширования. Более того, могу предположить что разработчикам просто тупо спустили метрику "Сконвертировать n индексов из неуникальные в уникальные" - Типа из общих соображений, как в 2012ой все отнормализовали из общих соображений. Вот они и сконвертировали
|
|
|
| Теги |
| index, indexunique, recid, индекс |
|
|
|
Комбинированный вид
