SAP или 1С?

[Ronin]

Здравствуйте, Recoilme!

С нетерпением ждал Вашего ответа. Мое подозрение на счет природы вашей проблемы окрепло. :-)

Насколько я понимаю, индех ItemIdx не изменялся в процессе внедрения? То есть он остался в том виде, в котором создался при инсталляции системы. Если так, то его структура должна быть следующей:
DataAreaID
ItemID
datePhysical.

Теперь, основываясь на имеющихся знаниях, проанализируем ваши запросы и их планы.
select sum(qty), itemID
from inventTrans
where datePhysical<'20041001'
group by itemID
order by itemID

оптимизатор не может найти эффективный индекс для выполнения данного запроса и решает, что раз надо получить все записи, то full scan будет достаточно оптимальным. Использовать индекс ItemIdx он не может по той простой причине, что в запросе отсутствует условие/сортировка/группировка по DataAreaID.

Если мы добавляем в конце опцию FAST 20, оптимизатор решает, что использование хоть какого-то индекса позволит быстрее получить первую партию записей. Напрасно считает :-) Но не его это вина и уж тем более не вина Аксапты. Просто для данного запроса ОТСУТСТВУЕТ эффективный индекс. По факту получается, что самым оптимальным планом является использование Full scan'а.

Что можно сделать.
1. Добавить в инструкцию WHERE фильтр по компании. Или добавить группировку по компании. Плохо, что этот вариант не позволит повысить селективность индекса, но может помочь.
2. Если компания используется одна, то есть смысл вообще убрать из индекса поле DataAreaID.
3. Создать еще один индекс со следующими полями: itemID, datePhysical, и коль мы часто используем в запросе наложения условий по статусам прихода и расхода, то включить в него StatusIssue, StatusReceipt.

При использовании индекса подобного тому, что описан в пп.3, ваш запрос обрабатывался на реальных объемах (15 000 000 записей) 1 минуту и 4 секунды.

Про индексы очень хорошо описано в статье http://www.sql.ru/articles/mssql/03013101Indexes.shtml

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

[mazzy]

Ronin, спасибо.

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

Цитата:

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

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

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

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

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

[mifi]

Цитата:

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

Ronin, спасибо.

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

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

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

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

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

[mazzy]

Цитата:

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

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

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

[mifi]

Цитата:

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

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

В смысле? При чем тут гильотина? Если у клиента одна компания и так будет очень долго и он принимает обдуманное решение - я не вижу здесь никакого криминала, с учетом того, что как мы уже установили, это можно сделать штатными средствами разработки.

[Recoilme]

Цитата:

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

В смысле? При чем тут гильотина? Если у клиента одна компания и так будет очень долго и он принимает обдуманное решение - я не вижу здесь никакого криминала, с учетом того, что как мы уже установили, это можно сделать штатными средствами разработки.

+1
У нас именно так и сделано. Сэйвдатаперкомпани отключен. В нашем случае гильотиной было бы оставить датаареаид ...

[Recoilme]

Цитата:

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

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

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