Цитата:
Сообщение от
Ivan
Но есть вопрос. Вы говорите по возможте создавать несколько мелких ключей, разве мы этим не увеличим время на выборку по фильтру из таблицы с промежуточными значениями?
Поясню по пунктам:
1. Теперь в Nav5 создается одна таблица с SumIndexField
2. Допустим в моей таблице 5 разных ключей с SumIndexField
3. Делаю SETCURRENKEY(Key3), потом SETRANGE(Field3,MyFilter3) и расчитываю CALCSUM(Qty)
4. Таким образом сначала необходимо будет отфильтровать таблицу по ключу, а потом посчитать сумму.
5. Не лучше создавать один длинный ключ?
Не совсем понял пример по пунктам, попробую пояснить свою мысль на крайнем случае.
Представьте себе - жил был длинный ключ с сифтами на таблице Value Entry из 10 вообщем-то нужных полей и тут
skipped недальновидный программист решил добавить в конец ключа поле Entry No. - то бишь первичный ключ таблицы. Как же это безобразие отразиться для Нав 4 и Нав 5?
Нав 4 - под новый уровень добавит число записей, равное числу записей в таблице Value Entry. Вообщем-то отчеты в производительности не потеряют, так как селективность практически не поменяется. Сильно проиграет учет, так как вынуждет будет обслуживать доп. уровень.
Нав 5 - тут трагедия. Число записей в индексированной вьюхе ставит равной числу записей в таблице Value Entry. Немного проиграет учет, а вот отчеты вместо обработки агрегированных данных будут лопатить по сути ту же Value Entry.
Резюме для Нава 5 такое - чем больше записей в индексированном представлении, тем медленнее работает расчет сифт полей. Если есть возможность уменьшить число записей в индексированном представлении - следуюет ею воспользоваться, один из вариантов - по возможности разбивать ключ на более мелкие.
PS. Есть варианты ускорить расчеты сифтов на пару порядков, например перестроя порядок полей в ключе и используя покрытые индексы. Очень хочется верить что в новой версии платформы MS в наконец то откажется от поддержки натив ДБ и использует все преимущества SQL сервера.