SAP или 1С?

[mazzy]

Ronin, спасибо.

Только, пожалуйста, будьте осторожны вот с такими советами...

Цитата:

Сообщение от Ronin

2. Если компания используется одна, то есть смысл вообще убрать из индекса поле DataAreaID.

Штатными средствами этого сделать не получится. А использование нештатных средств может сильно навредить новичкам.

Делать таблицу номенклатуры общей только для повышения производительности... все равно что лечить головную боль гильотиной.

А с остальным сов.согласен.

[mifi]

Цитата:

Сообщение от mazzy

Ronin, спасибо.

Только, пожалуйста, будьте осторожны вот с такими советами...

Штатными средствами этого сделать не получится. А использование нештатных средств может сильно навредить новичкам.

Делать таблицу номенклатуры общей только для повышения производительности... все равно что лечить головную боль гильотиной.

А с остальным сов.согласен.

Я тоже не стал бы советовать убирать DataAreaId, но почему это нельзя сделать штатными средствами, непонятно - свойство SaveDataPerCompany чем не штатное средство?

[mazzy]

Цитата:

Сообщение от mifi

свойство SaveDataPerCompany чем не штатное средство?

Этого я и боялся...
Не спорю, штатное. Но я же говорил - это все равно, что лечить мигрень гильотиной... Да, совершенно верно, голова больше болеть не будет...

[Recoilme]

Цитата:

Сообщение от Ronin

Здравствуйте, Recoilme!
Надеюсь мне удалось немного поднять репутацию Аксапты ;-)

Соб-но репутация аксапты мне безразлична Мы работаем на ней и я считаю что это достаточно эффективный инструмент, позволяющий решать задачи.
Рано или поздно. Так или иначе.
В отличие от тех систем где задачи либо вообще невозможно решить, либо придется переписывать вообще всё для их решения
Но и особо восторгаться почему то не тянет
Надеюсь что когда-ть появятся настоящие клиент-серверные системы в моем имховском понимании этого словосочетания. На которых можно будет приятно и комфортно решать поставленные задачи не парясь по поводу быстродействия, глючков и багофичей .
Пока я вижу такие только в зародышевом состоянии. Вобщем сильно тянет в оффтопик, завязываю.
Аксапта вобщем рулит, только иногда на поворотах заносит.

[AndyD]

2 Recoilme

А в вашем запросе все правильно?
Вы выбираете проводки (до даты и со статусом прихода закуплено, получено или зарегистрировано) или (со статусом расхода отпущено, скомплектовано или продано).
Т.е. у вас выбираются все расходные проводки, а приходные проводки только на дату.

[Recoilme]

Цитата:

Сообщение от AndyD

2 Recoilme

А в вашем запросе все правильно?
Вы выбираете проводки (до даты и со статусом прихода закуплено, получено или зарегистрировано) или (со статусом расхода отпущено, скомплектовано или продано).
Т.е. у вас выбираются все расходные проводки, а приходные проводки только на дату.

Это просто пример несложного запроса и неэффективности повсеместного использования аксой оптионфаста, условия по статусам - вообще убраны. Корректный вариант этого запроса можно найти по ссылке в подписи в уголке проктолога

[Recoilme]

2 Ronin;

Чего то я с этими индексами совсем запутался.. Может быть подскажете эффективный индекс для данного запроса (с оптионфаст) ???
Потому что вроде у нас как раз такой индекс который Вы описываете (без датаареаид). Индекс по одинокой датефизикал оптимизатор тоже не хочет использовать, наверно из-за инструкции орддербай по итемид.

[Ronin]

Почему бы не подсказать, подскажу.

В дереве AOT это поле не отображается. Но если вы посмотрите на этот индекс из Enterprize Manager'a или Query Analyzer'a, то его увидите. AOT - не лучшее средство для анализа и Perfomance tuning'а. В дереве AOT вы не увидите и некоторых полей в таблицах, которые однако существуют физически и отображаются в обозревателе таблицы или паспорте записи.

Как избавиться от данного поля - есть 2 пути.

1. Как написал mifi, используйте свойство SaveDataPerCompany. Это свойство таблицы. Благодаря данному свойству вы можете избавиться от поля dataareaid и в таблице и в индексе.
2. Создайте свой индекс.

Почему оптимизатор не строит план запроса с использованием данного индекса. Order by тут ни причем. Более того, использование order by наоборот побуждает использовать индекс, в котором имеется данное поле. Вот цитата из той ссылки что я вам давал ( http://www.sql.ru/articles/mssql/03013101Indexes.shtml ):


16.3

В создании композитного (сложного) индекса участвуют несколько полей таблицы. При создании индекса следует обращать внимание на порядок следования полей в индексе.

Например, если создается индекс по полям Field1, Field2, то он может быть применен только в запросе где в критериях используются оба этих поля. Так же этот индекс будет полезен для условий, построенных для одного Field1. Для одного Field2 этот индекс не может быть применен.

Так же обратите внимание на обслуживание статистики. Пункт 14.

[Recoilme]

Цитата:

Сообщение от Ronin

Почему бы не подсказать, подскажу.

В дереве AOT это поле не отображается. Но если вы посмотрите на этот индекс из Enterprize Manager'a или Query Analyzer'a, то его увидите. AOT - не лучшее средство для анализа и Perfomance tuning'а. В дереве AOT вы не увидите и некоторых полей в таблицах, которые однако существуют физически и отображаются в обозревателе таблицы или паспорте записи.

У нас нет этого поля. Выше я ответил Михаилу, что именно так у нас и отключено.

Искусственный интелект оптимизатора подсказывает, что в данном запросе эффективного индекса быть не может. Что ему можете противопоставить Вы?

[Ronin]

Recoilme, чудес не бывает.

Если оптимизатор на таком простом запросе строит план по full scan, такому его решению есть вполне объективные причины. Его искуственный инетеллект не настолько уж и плох. И противопоставлять ему ничего не надо. Наоборот, ему надо помогать всеми возможными средствами

Причин по большому счету может быть 2.
1. Отсутствие эффективного индекса. Вероятность 90%
2. Проблемы со сбором и обновлением статистики. Вероятность в данном случае 9%.
3. Прочий полтергейст. Вероятность не более 1%.

[Vadik]

Мои пять копеек - (ItemId, DatePhysical, Qty), если забыть про фильтры по StatusReceipt и StatusIssue

Другие (не покрывающие) индексы при таком количестве данных (если мне память не изменяет, порядка 4 миллионов записей в InventTrans на дату) либо не будут использоваться, либо bookmark lookup-ы сделают доступ дороже table scan-а, что собственно и было продемонстрировано выше.

P.S. Забавное обсуждение, особенно если взглянуть на название ветки

[mifi]

А в чем корень проблемы, удалось установить - в order by или в optionFast?. И если в optionFast - то для всех значений (1,2, 20, 100) или только для определенных?

[Recoilme]

Действительно. Вот собственно и сравнили SAP с 1Сом

PS: мусолить дальше тему запросов/оптимизаторов/хинтов/индексов - лениво.

[Ronin]

Чтобы закрыть тему индексов окончательно, позвольте поделиться великим и сокровенным знанием о том, чем будет отличаться индекс предложенный 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 - на усмотрение читателя сего опуса.

[Recoilme]

2 Ronin: Со всем согласен, но думаю топиг нельзя будет считать до конца закрытым не добавив небольшого уточнения.

Здесь на мой непритязательный взгляд достаточно наглядно изложены физические причины торможения такого рода.

Вобщем добавил бы:

Вывод 5: не так страшен натурал как его малюют.

Хотя как говорится на вкус и цвет.