AXForum  
Вернуться   AXForum > Рынок > Сравнение ERP-систем
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 05.04.2006, 17:25   #38  
Ronin is offline
Ronin
aka awas
NavAx Club
 
16 / 30 (2) +++
Регистрация: 21.06.2004
Адрес: г. Москва
Чтобы закрыть тему индексов окончательно, позвольте поделиться великим и сокровенным знанием о том, чем будет отличаться индекс предложенный Vadik'ом от индекса только по (ItemId, DatePhysical).
Скриншоты с планами запросов я приводить не стану - их можно посмотреть выше.

Интрига вкратце: при использовании очень схожих индексов время выполнения простого запроса отличалось на 2 порядка. Причем объемы таблиц были сопоставимы.

Почему.
Если посмотреть на планы запросов, то можно увидеть следующее - они отличаются не способом поиска записей (что там, что там используется индекс, причем используется по 2м полям ItemId, DatePhysical), а тем как считается сумма.
В быстром случае используется Stream Agregate, в медленном - Bookmark Lookup.
Теперь посмотрим, чем отличаются эти 2 оператора. Для этого воспользуемся хелпом Query Analyzer'a.

The Stream Aggregate physical operator optionally groups by a set of columns and calculates one or more aggregate expressions returned by the query and/or referenced elsewhere within the query. This operator requires that input is ordered by the columns within its groups.

Bookmark Lookup
The Bookmark Lookup logical and physical operator uses a bookmark (row ID or clustering key) to look up the corresponding row in the table or clustered index.

Иными словами, Bookmark Lookup для того чтобы просуммировать поле qty должен "вытащить" из таблицы все найденные записи, чтобы прочитать значение поля. А fetch операция обычно достаточно долгая.

Возникает вопрос, а что Stream Aggregate разве за значением данного поля в таблицу не лезет? В том то и дело, что нет. Для этого опреатора, необходимо чтобы поле, по которому "работает" агрегирующая функция было упорядочено в данной группировке, иными словами, чтобы оно присутствовало в индексе, по которому строился план запроса.

Таким образом...
А что "таким образом"... да собственно ничего. Я хотел сказать, что дальше выводы сделать не трудно.
Вывод 1 - Fetch операция долгая
Вывод 2 - Понимание плана запроса позволяет сохранять нервные клетки
Вывод 3 - Век живи, а все равно всего не изучишь.
Вывод 4 - на усмотрение читателя сего опуса.
За это сообщение автора поблагодарили: George Nordic (5).
Теги
1c, sap, sql, оптимизация, производительность, сравнение систем

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Изменения ассортимента, цен, условий поставки и сопровождения ряда продуктов «1С:Предприятия 7.7» mazzy Другие системы на рынке 40 30.04.2008 23:31
Обсуждение документа "Сравнение 1С и AX" Кузнецов Александр Сравнение ERP-систем 44 20.02.2008 13:56
1С собирается бить SAP на его территории... Сисой Другие системы на рынке 1 10.04.2007 17:27
Платформа «1С:Предприятие» как средство разработки бизнес-приложений Morpheus Другие системы на рынке 1 26.12.2006 13:10
1С ищет стратегического инвестора Роман Кошелев Другие системы на рынке 1 16.04.2003 23:02

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 04:23.