Когда таблица одна-две, то больщой необходимости в хранимых процедурах, как правило, нет. Но когда их тысячи, и логика выборки информации из них довольно сложна, то лучше разместить эту логику на SQL-сервере. Каждый раз, когда на SQL-сервер приходит запрос, SQL-сервер строит план его выполнения и компилирует. На это расходуются ресурсы сервера. Хранимые процедуры позволяют один раз на всю жизнь скомпилировать какой-то очень сложный скрипт, в котором могут быть циклы, ветвления и много чего другого, а не расходовать впоследствии ресурсы сервера при каждом запуске подобного скрипта. Кроме того, динамически далеко не все запросы удобно и формировать. Попробуй-ка динамически сформировать SQL-запрос, в котором имеются опреаторы ветвления и цикла. Нет, конечно, сделать всё можно. Но зачем? Динамически можно построить один "select..." или "exec...", но что-то более сложное формировать динамически на клиенте - это просто маразм (imho).

Alexey RovdoРазумеется, использование хранимых процедур повышает быстродействие - и это очевидно. Но оно снижает возможности использования других СУБД, кроме той одной единственной, для которой уже написаны тысячи хранимых процедур. Ведь при переходе к другой все эти тысячи прийдется переписывать.Совершенно верно. Поэтому смотреть нужно по месту - что важнее. Возможность работать с разными SQL-серверами, многоплатформенность, либо быстродействие. Если проект начинается с нуля и есть возможность самим определять все аспекты внедрения, то, ПМСМ, лучше сориентироваться на ERP-систему менее универсальную, более заточенную под конкретный SQL-сервер. Работать будет существенно быстрее, код будет более качественный, стоить будет дешевле. Но если на разных производственных площадках, взаимодействующих между собой, уже установлены разные SQL-сервера и лицензионные операционки (разные), то можно сэкономить на приобретении новых лицензий для именно этого софта, выбрав ERP-систему, которая сможет работать с разными SQL-серверами и на разных платформах, и при этом площадки смогут достаточно прозрачно друг с другом взаимодействовать. В России, где процветает пиратство, именно этот вопрос так остро не стоит. Но даже если бы все пользовались только лицензионным софтом, он все равно не был бы главной причиной, по которой многие производители ERP-систем делают свой софт многоплатформенным и способным работать с разными SQL-серверами.
Как я понимаю, это вопрос не удобства для потребителя, а вопрос увеличения объема продаж для разработчика ERP-системы. Потребители могут выбрать другую ERP-систему только по одной простой причине. Потому, что другая ERP-система может работать именно в той операционной системе и с тем SQL-сервером, который ИТ-специалистам именно этого предприятия кажется более предпочтительным. На самом деле объективные предпосылки при выборе того или иного SQL-сервера в подобных случаях, особой роли не играют. Субьективность, привычки, пристрастия, предпочтения - вот что оказывается более весомым. И для того, чтобы нейтрализовать негативное действие этого фактора на объемы продаж, производители делают один и тот же продукт сразу подо всё, жертвуя при этом скоростью работы, нерациональным использованием вычислительных ресурсов и т.д. и т.п. Да, такова селяви... Несовершенные потребители воздействуют на производителей ERP-систем, которые в результате создают несовершенные ERP-системы в угоду потребителям, одновременно им же создавая лишнии проблемы.

Но это далеко не единственный и далеко не главный аспект несовершенства большинства ERP-систем. С моей точки зрения, совершенная серийно поставляемая ERP-система должна:
1. Быть относительно дешевой (доступной для малых предприятий)
2. Наиболее оптимально использовать вычислительные ресурсы
3. Включать в себя ВЕСЬ необходимый для управления предприятием функционал. То есть, включать в себя CRM, CAD, CAM, SCADA, все виды параллельных учетов. Быть адаптируемой под любое предприятие - производственное, торговое, проектное, научное, с дискретным, с поточным производством, и даже для общественных объединений любителей гадания на кофейной гуще.
Мечты, мечты... Не более. Я, разумеется, реалист... :)

avilm Alexey Rovdo

Интерестно как это ты будешь строить динамический запрос внутри хранимой процедуры если тебе неизвестны параметры этого запроса?
То есть грубо говоря у меня может быть от 1 до 150 (в зависимости от случая) различных параметров, исходя из которых строится сам запрос.
Это что же получается? Ты предлагаешь внутри хранимой все возможные варианты разобрать?Ничего, если я отвечу?
Точно так же, как это строится на клиенте. Если на клиенте анализируются 150 параметров, то точно так же их можно анализировать на сервере. Если на клиенте можно построить ветвления, в которых перебираются одни груды вариантов и отсекаются другие, то точно так же это можно сделать на сервере, если только это не совсем уж простенький сервер аля MySQL или Linter, в котором с процедурными расширениями языка запросов большая напряженка.

2 Ден. Я не понял, что именно оказалось удобным. Вы установили несколько вариантов одной ERP-системы, базирующихся на разных СУБД? Или вы прилинковали к MS SQL Server, с которым работала ERP-система несколько других SQL-серверов? Для второго случая я не вижу необходимости в поддержке ERP-системой СУБД Oracle, например.

avilmНу во первых количество параметров мне заранее не известно. Во вторых анализа параметров на клиенте не происходит. Грубо говоря в одном случае у меня 2 параметра на основе которых я должен построить условие "where" для запроса, во втором случае у меня уже 20 параметров и т.д. Здесь совсем не нужно эти параметры анализировать. Просто бери и клепай себе условие "where", да и кол-во параметров не ограничено.А " случаи " вы друг от друга как отличаете?

Ans1такое впечатление, что большинство понимает под хранимыми процедурами для ERP реализацию бизнес логики. Но ведь можно
а) бизнес-логику реализовать отдельно (3-х уровневая архитектура, как программная, так и аппаратная)
б) использовать хранимые процедуры только для реализации запросов.Давай попробуем разобрать конкретный пример. Допустим, необходимо пройтись по некоторой выборке в 1000 записей в цикле и в зависимости от содержимого этих записей и заданных вовне условий выполнить в теле этого цикла запросы на обновления данных, одни либо другие (какие именно, зависит от условий). Можно эту логику вынести на клиента или в промежуточный уровень (на самом деле, разницы никакой нет для рассматриваемого примера), а можно реализовать целиком на стороне SQL-сервера.

Вариант 1. Реализация на клиенте, либо на "промежуточном уровне".
Клиент делает запрос "SELECT..." и получает выборку записей, которую в цикле необходимо проанализировать. Затем он организовывает цикл (на клиенте или промежуточном уровне) средствами ЯВУ и посылает 1000 разных запросов на обновление на SQL-сервер. Либо он формирует один пакетный запрос, содержащий 1000 команд "UPDATE...", объемом в несколько мегабайт, и отправляет запрос один раз, но потом полчаса ждет, пока SQL-сервер разберется в том, что это за "войну и мир" ему прислали.

Вариант 2. Реализация на SQL-сервере".
Создается хранимая процедура, в теле которой организуется цикл по курсору и в зависимости от условий выполняются одни команды "UPDATE...", либо другие.

Скажите откровенно, какой из вариантов будет работать быстрее. И останется ли разница в скорости выполнения одного и того же алгоритма обработки данных в пределах 20%. По моим оценкам, скорость будет оличаться в несколько раз (возможно, в десятки раз).

2 AnS1. Вы совершенно правы, такие процедуры запускают ночью. Но соверменная ERP-система должна уметь "синхронно планировать", а не по ночам. Звонит клиент в сбыт и спрашивает, нельзя ли поставить два вагона жевачки к 15 февраля. И работник отдела сбыта должен тут же ответить - смогут или не смогут. А если не смогут, то к какому сроку смогут. При этом "на лету" производится расчет моментов возникновения потребности в материалах, загрузка производственных мощностей, согласованность и распианием работы трудовых ресурсов и многое другое. Это называется "синхронное планирование". Подобная функциональность автоматом переводит ERP-систему в ранг системы ERP-II по классификации Gartner Group. То есть, увеличение скорости дает качественный выигрыш, который ранее был недостижим. И тут уже счет идет на секунды. Одна система заставит держать трубку у уха полчаса, вторая даст ответ через 30 секунд. Как вы полагаете, какая из них больше подойдет заказчику?

AnS1В действительности, я и сейчас смогу сказать, будет ли у меня к 15 февраля (какого года кстати :)) 2 вагона жевачки - на основании данных ATP + MRP, если позволяет горизон планирования потребности. Другой вопрос, если у нас с вами не просто продажно-закупочная деятельность, а имеется производство, и эту жевачку надо еще изготовить.Я имел в виду именно "другой вопрос", то есть производственное предприятие. :)

AnS1Подозреваю, что и в этом случае можно обойтись без update по 1000 строк. Сейчас, если товара нет, то возникает потребность из сбытового заказа на определенную дату, затем отрабатывает плановик MRP и так далее...Да, вся загвоздка в этом самом "и так далее..." :) MRP производит расчет нетто- и брутто-потребностей и моментов их возникновения, отсупает во времени необходимые логистические, транспортные и операционные задержки, и получает моменты, в которые необходимо говорить "дзинь" соответствующим исполнителям, по какому поводу и какие количественные характеристики в это "дзине" необходимо отразить. Но проблема в том, что стандартный алгоритм MRP работает исходя из заведомо неверного предположения о том, что производственные мощности являются бесконечными. Для того, чтобы исправить ошибки, которые возникают в результате этого допущения, результаты MRP-расчета подают на вход алгоритма CRP, который занимается только выравниванием загрузки производмтвенных мощностей, наплевав на логистические задержки и кучу другой информации, которой оперирует MRP. В результате работы алгоритма CRP происходит сдвиг во времени моментов возникновения потребности тех или иных узлов и материалов. И требуется повторно прогнать алгоритм MRP, чтобы скорректировать аналогичные параметры у зависимых позиций. После чего снова прогнать CRP, дабы опять выровнять закрузку производственных мощностей... и т.д. и т.д. и т.д. Так работает Closed Loops. И работать он так может всю ночь. И нет 100%-ной гарантии, что в итоге он получит результат, который не требует корректировки. (Примечание: Если Closed Loops зациклился, то его останавливают принудительно на этапе, когда расчитана очередная итерация MRP, а CRP еще не отработал, и решают уже организационными методами, как бороться с перегрузкой имеющихся производственных мощностей).
Для синхронного планирования MRP НЕ сипользуется. Для этого используются алгоритмы APS, использующие совсем другие принципы и другую математику. Хотя решают они практически те же задачи, только совсем с другой скоростью.

AnS1Вопрос - а может ли менеджер по продажам принять решение о производстве 2-х вагонов жевачки за 30 секунд? Позволяет ли ему это сделать его компетенция? Согласуются ли поставки комплектующих для жевачки со планом закупок на период? Расходы в бюджет включаем тоже автоматически?Очень важные вопросы, хорошо, что они прозвучали. Производство может быть:
- Под прогноз
- Под заказ
- Комбинированное.
На том предприятии, которое преимущественно работает под прогноз, ERP-система, ПМСМ, вообще не нужна. Достаточно один раз в год (или в десять лет) на всю будущую жизнь сделать один, пусть даже сложный, расчет - и далее просто стараться следовать полученным результатам. Реальный выигрыш ERP-система дает только там, где "всё течет и всё меняется", где заранее предсказать, что, когда и где потребуется, невозможно. И это именно производство под заказ. На предприятии, работающем под заказ, разумеется, тоже имеет место стратегическое планирование. Но задачей этого планирования отнюдь не является ограничение приема заказов заданными сверху цифрами. Если факт существенно отличается от плана, все равно стараются приспособиться под реальную рыночную ситуацию. Иначе предприятие просто потеряет клиентов и доверие рынка. Стратегическое планирование нацелено на предсказание изменения спроса в связи с коньюнктурой, изменением потребностей потенциальных клиентов и своевременном изменении производственной базы - сворачивании одних видов деятельности и расширении других. Комбинированное производство (под прогноз + под заказ) обычно используется для сглаживания загрузки производственных мощностей при сезонных колебаний спроса на продукцию.
Таким образом, если предприятие создано , и у него имеются вполне определенные стратегические цели , суть которых доведена до исполнителей, то рядовой исполнитель, а именно, менеджер по продажам, имеет полное право принять новый заказ. НО!!! Только при условии, если он точно знает, что прием этого заказа не вызовет ни одного из следующих последствий:
- дефицит денежных средств на расчетном счете из-за возросших расходов на обеспечение текущих заказов
- перегрузку производственных мощностей
- формирование невыполнимых задач перед отделом закупок
- переполнение хранилищ
- несогласованность с расписанием работы трудовых ресурсов
- и т.д. и т.п.
- можно еще добавить соответствие каким-либо лимитам, расчитанным при стратегическом планировании, если действительно есть такая необходимость... :)
Так вот, если никаких подобных рассогласований не происходит, то рядовой исполнитель может быть уверен, что он действует в рамках своей компетенции, и что его действия направлены на достижение стратегических целей. Задача ERP-системы как раз и заключается в том, чтобы отделить мух от котлет и предоставить каждому менеждеру на каждом уровне и на каждом рабочем месте заниматься именно своим делом, а не устраивать "птичий базар". Топ-менеджмент НЕ ДОЛЖЕН вникать в каждый рабочий вопрос, особенно, если всё идет по намеченному стратегическому плану. Он должен решать стратегические вопросы. И он должен вмешиваться в оперативные задачи только в тех случаях, когда случилось что-то экстраординарное. Например, поставщик нарушил свои обязательства. Или случилась серьезная поломка на производственной линии, которая на длительное время остановила производство. Или появился крупный заказчик, который просит выполнить его заказ в нереальные сроки, но на очень выгодных условиях (может быть, передвинуть сроки выполнения других заказов?). Именно о такой ERP-система мечтает топ-менеджмент, когда ухает на это дело огромные суммы. :)

AnS1хотел бы я посмотреть на такую систему. причем в действии...Можешь посмотреть, как это работает в холдинге Метран , например. Всё, что я выше сказал - относительно ново даже для западных стран (Garnter Group объявил конец эры ERP-систем и начало эры ERP-II-систем в октябре 2000 года). Подробнее можно почитать в книжке Питеркина (сейчас этот автор готовит к выпуску вторую свою книгу, жду ее выхода с нетерпением). Пока у нас, в России, даже MRP считается великим достижением. :)