SAP или 1С?

[Тимур]

Согласен.
Я вот проглядел так называемое "исследование", которое провела компания Nucleus Research.
http://www.nucleusresearch.com/toolb...P%20Oracle.pps
(вот тут размещали ROI analysis you can trust (tm)
как ROI анализ, мол "которому можно доверять".)
Тьфу в общем на такой анализ.
Как можно сравнивать задачи крупных компаний и маленьких ? Как можно просто взять 10 предприятий, внедривших один продукт, 10 - другой и еще 10 - третий? Если масштабы и отрасли этих предприятий разные!
А Евросеть это все делает только для чистых понтов: демонстрация "прозрачности" перед инвесторами. Как будто инвесторы справки не могут навести о том, каким образом осуществляется импорт товара в Россию этой компанией и как выплачивают заработную плату персоналу.

[vleg]

Цитата:

Сообщение от Тимур

Согласен.
Я вот проглядел так называемое "исследование", которое провела компания Nucleus Research.
http://www.nucleusresearch.com/toolb...P%20Oracle.pps
(вот тут размещали ROI analysis you can trust (tm)
как ROI анализ, мол "которому можно доверять".)
Тьфу в общем на такой анализ.
Как можно сравнивать задачи крупных компаний и маленьких ? Как можно просто взять 10 предприятий, внедривших один продукт, 10 - другой и еще 10 - третий? Если масштабы и отрасли этих предприятий разные!

Плохо, конечно, сравнивать разные предприятия. Но не в этом случае. ROI - он же универсальный инвестиционный показатель. Представь, что ты сравниваешь доходность от своих вложений в разные активы - в банковские депозиты, голубые фишки или акции второго эшелона. Одинаковые ли по своей природе эти активы? Нет конечно. Но тебе, как инвестору, без разницы, как работают деньги там, куда ты их вложил. Ты в итоге заработал больше или меньше. И всего то. То же и про ROI.

[Тимур]

Цитата:

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

Плохо, конечно, сравнивать разные предприятия. Но не в этом случае. ROI - он же универсальный инвестиционный показатель. Представь, что ты сравниваешь доходность от своих вложений в разные активы - в банковские депозиты, голубые фишки или акции второго эшелона. Одинаковые ли по своей природе эти активы? Нет конечно. Но тебе, как инвестору, без разницы, как работают деньги там, куда ты их вложил. Ты в итоге заработал больше или меньше. И всего то. То же и про ROI.

Владимир. Спасибо за пример. Я прекрасно понимаю о чем идет речь.
Но дело в том, что когда 2 разных предпрития начинают 2 разных проекта по внедрению двух разных систем, то это суть 2 разных инвестора, у которых есть альтернативы в виде этих двух систем, но в результате мы МОЖЕМ получить следующее сравнение:
Компания уровня "Боинг" внедряет OEBS и ROI у этого проекта мизерный.
Компания типа "Объединенные ларьки возле северного выхода из м. Алтуфьево" внедряет таблицу Excel и ROI у этого проекта офигенное.
Так что с того?
Возможно ли предложить инвестору проекта компании "Боинг" альтернативу в виде таблицы Excel?
Инвесторы не просто выбирают глупо проект с наивысшим ожидаемым ROI. Для анализа выбираются сопоставимые альтернативы.

На мой взгляд в исследовании компании Nucleus Research тема сопоставимости и альтернатив вообще не раскрыта. Нет, я не исключаю того, что аналитики компании добросовестно сравнили сопоставимые объекты автоматизации с одинаковыми задачами. Но вот в презенташке об этом ни слова нет.

[vleg]

Думаю, что по задачам - объекты сравнимые (посмотрите слайды по TCO, они же сами декларируют, что сравнивать надо сравнимое), по масштабу они - очевидно, разные - на эту тему есть отдельный слайд.

[mazzy]

Телекоммуникационный вендор взял на вооружение "малый" SAP
Выбор системы начался в августе 2005 года. В результате него специалисты OlenCom Electronics остановились на двух альтернативных решениях: "1С" версии 8.0 и SAP Business One. «В итоге предпочтение было отдано SAP. Дело в том, что, по оценкам экспертов, системы от «1С» ориентированы прежде всего на учет и уже во вторую очередь - на другие бизнес-процессы. Основная цель нашего проекта – автоматизация работы сотрудников отдела продаж, снабжения и обслуживания клиентов (CRM), что должно увеличить скорость прохождения заказов, повысить оперативность работы данного подразделения", - сообщил Владимир Карвосеноя.

Подробнее...
http://www.spbit.ru/news/n7409/

[Тимур]

Так вот в той самой презенташке, где делаются хвалебные выводы в пользу Аксапты, про сопоставимость объектов анализа нет ни слова.
Так и представляю, как продавцы оного продукта возьмут эти слайды на вооружение.

[Recoilme]

По 1 - категорически не согласен. Аксапта этим хинтом заставляет оптимизатор конкретно тупить. Если в САПе этим рулит разработчик - +1. имхо

А в целом - разочаровался в архитектуре сапа. И что самое смешное - я не один такой идиот. Вчера только общался с одним ит-директором о том, что к сожалению ни одно полнофункциональное бизнес-приложение не использует преимуществ клиент-серверной архитектуры. Как следствие - для всех характерно низкое быстродействие.

[mifi]

Цитата:

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

По 1 - категорически не согласен. Аксапта этим хинтом заставляет оптимизатор конкретно тупить. Если в САПе этим рулит разработчик - +1. имхо

А в целом - разочаровался в архитектуре сапа. И что самое смешное - я не один такой идиот. Вчера только общался с одним ит-директором о том, что к сожалению ни одно полнофункциональное бизнес-приложение не использует преимуществ клиент-серверной архитектуры. Как следствие - для всех характерно низкое быстродействие.

А в чем проблема с пунктом один? Поставьте флаг, который был указан в топике Управлении опциями SQL-запроса - Управление опциями SQL запроса в поле hint flags на закладке Database конфигурационной утилиты и не будет хинта.

[Recoilme]

Вобщем думаю да, но есть ещё такие понятие как:
1. Качество кода
2. Реализация бизнес логики
3. Особенности реализации динамического скуэль
4. Практика
Примеры:
1. Если код написан неоптимально - никакие архитектурные фьючерс не помогут
2. Если 1С при формировании проводок по списанию каждый раз по ФИФО себестоимость рассчитывает - она хоть удавится будет медленная черепаха
3. Если аксапта хинт бездумно во все запросы лупит - будет тормозить на тех запросах где хинт не нужен
4. Если САП работает на 200 одновременных пользователей, а 1С - нет - можно хоть до опупения тут обсуждать особенности архитектуры Все эти выводы яйца не стоят

[Recoilme]

по п.1
Хотелось бы чтобы при открытии справочников и журналов этот хинт юзался. При выполнении запросов в коде этот хинт не добавлялся автоматически. Тогда и интерфейс не тормозит и сложные запросы не тупят.
А в аксапте или дудочка или кувшинчик получается.

[mifi]

Цитата:

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

по п.1
Хотелось бы чтобы при открытии справочников и журналов этот хинт юзался. При выполнении запросов в коде этот хинт не добавлялся автоматически. Тогда и интерфейс не тормозит и сложные запросы не тупят.
А в аксапте или дудочка или кувшинчик получается.

А можете привести пример запроса, который сильно тупит именно из-за option fast?

[Recoilme]

PHP код:

while select  ItemId, Sum(Qty) from It
    group by ItemId
    Where (It.DatePhysical < startDate) && (It.StatusReceipt==StatusReceipt::Purchased || It.StatusReceipt==StatusReceipt::Received || It.StatusReceipt==StatusReceipt::Registered) ||
        (It.StatusIssue==StatusIssue::Deducted || It.StatusIssue==StatusIssue::Picked || It.StatusIssue==StatusIssue::Sold) 


хинт заставляет мс скуэль юзать составной индекс итемид/датефизикал на условии датефизикал. В результате разница в быстродействии с Хинтом / без хинта составляет >1,5 часа(не дождался, снял задачу)/ 1,5 минуты соответственно.

ЗЫ: без хинта - план по инвенттрансу - натурал

[Ronin]

2 Recoilme:
Ваш пример заинтриговал меня :-)
Чтобы проверить влияние данной опции на производительность я запустил подобный запрос в Query Analyzer'е.

select ItemId, Sum(Qty)
from InventTrans
Where DatePhysical < '20060301'
and ( StatusReceipt = 1 or
StatusReceipt = 2 or
StatusReceipt = 3 or
StatusIssue = 1 or
StatusIssue = 2 or
StatusIssue = 3)
group by ItemId
--option (fast 1)


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

[Recoilme]

Вы слишком хорошо думаете об аксапте. Надо выполнить запрос из аксапты и извлечь его из профайлера, а потом убрать хинт оптион фаст и удивиться. Запрос из аксапты будет отличен от того что Вы думаете, что аксапта напишет

[Ronin]

В случае селекта из одной таблицы он будет отличаться только большим количеством скобочек. Кстати, индекс, который используется при выполнении вышеприведенных запросов - сложный, который строится по 7ми полям, первые 2 как раз itemID и datePhysical. Возможно именно это объясняет высокую эффективность данного индекса в этом запросе. Впрочем, если Вы получаете иные результаты, интересно было бы посмотреть на запрос, который запускает аксапта с планом и на структуру используемого индекса.

Плохо о ней я начинаю думать при составлении сложных запросов. Там да, она может запрос с outer join представить двумя вложеными запросами типа
while select
{
while select
{
}
}
В свое время меня это очень неприятно удивило.

[Recoilme]

Цитата:

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

В случае селекта из одной таблицы он будет отличаться только большим количеством скобочек.

Не только. Ещё ордер баем будет отличаться. И соответственно - планом.

Мне некогда гонять этот запрос опять, сорри. В свое время я на эту проблему целый день убил пока разобрался. Если интересно - проверьте сами.

Вообще если эту тему разроете чуть глубже - и получите отличные от моих результаты на реальном тесте, а не на абстракном запросе из QA - обещаю подключиться ибо хотелось бы подетальней разобраться в причинах

[Ronin]

Добрый день, Recoilme!

Не хочу показаться занудным, но отдаю себе отчет в том что данное письмо будет засчитано именно как махровое занудство :-)

Вы писали "хинт заставляет мс скуэль юзать составной индекс итемид/датефизикал на условии датефизикал. В результате разница в быстродействии с Хинтом / без хинта составляет >1,5 часа".

Я же хотел сказать, что само по себе выбор составного индекса не может практически на 2 порядка "тормознуть" выполнение данного запроса. Проиллюстрировал это на примере.
Order by по тому же полю, что и group by в данном случае на выбор оптимизатором индекса не повлияет. Иначе это уже будет огромный камень в огород MS SQL и поводом к выпуску хотфикса, а не генератора запросов Аксапты. На мой взгляд причина описаной вами проблемы лежит в плоскости оптимизации используемой базы данных.

Чтобы не осталось белых пятен, могу сказать, что ваш запрос, запущенный в Job'е из Аксапты отработал не медленнее, чем его аналог в Query Analyzer'e. При этом тестировались 2 разновидности запроса с разными условиями во WHERE:
(Проверка даты) && (Статусы прихода || Статусы расхода)
и ваш запрос
(Проверка даты) && (Статусы прихода) || (Статусы расхода)


Есть не мало примеров тому, когда у оптимизатора "сносило крышу". Сносить ее может начать например из за большого количества неэффективных индексов по таблице. Однако на практике я наблюдал подобные эффекты на более сложных запросах, чем селект с группировкой из одной таблицы.

[Recoilme]

Маленькое замечание: "тестиррование проводилось на реальных объемах, индексы штатные (ItemIdx)"

[Recoilme]

что то видно плоховато, дубль 2

[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

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