Обработка накладной в заказе больше 10 минут для 200 строк

[AndyD]

Цитата:

Изначально опубликовано sao
Еще вопрос: Почему у многих таблиц нет Primary key и кластерных индексов в стандартном функционале?

А что по вашему такое Primary key?
Primary key - это ограничение (constraint), которое гарантирует, что набор значений столбцов, входящих в него, будет уникальным в таблице. При этом он также требует, чтобы эти значения были определены, т.е. IS NOT NULL.
Кроме того, существует еще одно ограничение, требующее уникальности - UNIQUE. Но при этом значения стобцов могут быть не определены (IS NULL).
И как-раз таки это ограничение всегда присутствует в таблице, даже если не создавать индексы. В этом случае создается уникальный индекс на основе поля RecId (и DataAreaId, если таблица разбивается для компаний. Точнее порядок полей в индексе - DataAreaId, RecId). Если же существуют только неуникальные индексы в таблице, то тогда к первому из них так же добавляется поле RecId и индекс объявляется уникальным (правда увидеть это можно только на сервере БД)

Таким образом ограничение на уникальность всегда присутствует в таблице в виде Primary Key или Unique Index.


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

Остальные индексы для таблицы могут ссылаться на данные двумя способами - либо ч/з Row ID если нет кластерного индекса, либо ч/з кластерный индекс в противоположном случае. Большой размер ключа кластерного индекса будет вести к увеличению размера остальных индексов, что ведет в конечном итоге к уменьшению производительности б/д.

Т.е. использование/неиспользование кластерных ключей - вопрос поиска компромиссов, результаты которых мы видим в Axapte