MazzyКаково ваше мнение: должна ли ERP-система использовать ХП?

Осмелюсь высказать свое имхо по данному вопросу. Только, возможно, он не совсем точно сформулирован. Должна/не должна - смотря с какой точки зрения, какие критерии принимать за основополагающие?

Если базовый критерий - многоплатформенность, то производители по понятным причинам стараются избежать использования хранимых процедур. В этом случае СУБД выступает в роли контейнера таблиц, и запросы к таблицам тоже стараются сделать унифицированными - чтобы они корректно отрабатывали на всех платформах. Естественно, производительность при этом теряется, иногда весьма существенно.

Если главное - производительность, а многоплатформенность существенного значения не имеет, то можно использовать особенности и возможности конкретной СУБД на всю катушку. Выиграв в производительности, проиграли в универсальности.

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

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

Таким образом, лично для себя я немного другим способом расставляю акценты. Не "правильно или неправильно, что BAAN работает с грудой разных СУБД", а нужно ли мне при решении практических задач использование разных СУБД. Готов ли я платить за многоплатформенность денгами и потерей производительности? Если нет, значит мне нужна ДРУГАЯ ERP-система. А кому-то другому, возможно нужна именно эта, потому что в разных филиалах используются разные СУБД.

Дополнение по поводу хранимых процедур. Широкое использование хранимых процедур в MS SQL Server обычно является признаком более тонкого клиента и особого подхода к вопросам защиты информации от несанкционированного доступа (когда доступ к таблицам пользователям закрыт). Но сам факт широкого использования хранимых процедур еще не является доказательством того, что их использование привело именно к повышению производительности, более тонкому клиенту и более строгому подходу к вопросам безопасности информации. Например, хранимые процедуры могут использовать динамический SQL, при этом настроить строго безопасность уже не получится.
Кроме того, использование хранимых процедур не является исчерпывающим решением для достижения трех перечисленных целей. В частности, вместо хранимых процедур могут использоваться VIEW с реализацией бизнес-логики на instead-триггерах и на обычных триггерах. А обычных хранимых процедур может быть раз-два и обчелся. А клиент получится тонким, скорость - реактивной, безопасность - строгой.

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

давайте рассмотрим, например, 1С. До недавних пор она не воспринималась на рынке как ERP-система. Сейчас, как я понимаю, 1С предпринимает усилия, чтобы выкарабкаться на этот рынок. Но их тянет файл-серверная концепция на DBF. Если бы им переориентироваться полностью под MS SQL, они смогли бы добиться более существенных результатов.

MazzyХм... скорее всего, это значит, что ты Garya работаешь не на MS SQL :)
Я не зря упомянул в вопросе про Юкон.

Если сейчас делать ХП для текущей версии, то на Юконе они либо не будут поддерживаться, либо будут работать неоптимально.

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

Мне кажется, мы друг друга где-то недопоняли. Или, может быть, я не точно высказался. Я как раз работаю на MS SQL. И это одна платформа, которая меня вполне устраивает.

Хранимые процедуры, написанные в старых версиях T-SQL совместимы синтаксически с Юконом. Поэтому я не вижу больших проблем в использовании старого кода ХП. За исключением, разве что, обращения к системным таблицам, которые в Юконе убрали. Другое дело - имеет ли смысл в идеологическом плане продолжать использовать старые концепции программирования, когда уже появились новые.
Под многоплатформенностью я понимал возможность раобты ERP-системы в разных ОС и/или с разными СУБД. В основном, второе. Например, с Oracle, Sybase, MS SQL, MySQL, и т.д.... Поскольку я не собираюсь использовать более одной конкретной СУБД ни сейчас, ни в будущем, мне эта многоплатформенность совершенно не интересна.

WhatevaТ.е. у клиента могут быть другое мнение / традиции / откаты / you name it, по этому вопросу.

Мне несколько проще. Я сам - клиент...

AnS1Что касает Юкона - а разве он позволяет "размазывать" БД на несколько физических серверов?

Имеется в виду кластеризация для увеличения пропускной способности? Еще в до-Юконовских MS SQL Server это можно было организовать с помощью раличных видов репликации (имея несколько копий одной базы данных на нескольких серверах). В Юконе появились новые возможности - использование т.н."теневого" сервера (только на чтение), например для формирования емких отчетов, чтобы они не тормозили OLPT-транзакции на основном сервере. Для этого варианта автобалансировка, конечно, проблематична. Но вопросы балансировки запросов к разным серверам данных может на себя взять сервер приложений.

Можно запустить на кластере MS SQL Server, и он сам будет заниматься балансировкой нагрузки. Правда, имхо, это не самое удачное решение.

Если же под "размазыванием" имеется в виду распределенные базы данных, то этот механизм давно можно использовать с помощью прилинкованных серверов и двухточечной записью обращения к объектам.

Если ни то, ни другое, то, может быть, имеет смысл уточнить, что именно имелось в виду.