iscrafm авторВот это "управление" мне не совсем понятно - растолкуйте, плиз.
Все просто. СП работает с СУБД в пакетном режиме. Ему (и клиентам) не нужно постоянно сидеть в он-лайне с БД. Поэтому не нужно на 50 пользователей иметь 50 конкурентных лицензий СУБД. Есть возможность регулирования, например на каждых 10 пользователей СП 1 лицензия СУБД. Клиент обратился к СП, СП к СУБД, получил свою порцию и отдал клиенту. Клиент спокойно работает со своим портфелем. Когда созрел - передает данные (вернее инструкции) СП, СП в свою очередь или исполняет инструкции сам и привлекает для этого СУБД. Опять же, повторяюсь, расчеты которые логично должна делать СУБД - делает СУБД.

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

модСервер БД - ОДИН (даже если это кластер) а апп. серверов можно поставить скока хошь - абсолютная масштабируемость. (И чего здесь не понятного ?)

Мне то все понятно. :) Если бы апп. сервера могли бы жить своей жизнь, а не использовать ОДИН сервер СУБД, то тогда можно было бы говорить о масшатабируемости. А так, скока мы бы апп. серверов не поставили рядом с одним сервером СУБД узкое место все равно останется в последнем, ибо данные на нем.

СисойВ СУБД (как правило) НЕТ ОТКРЫТЫХ ИНТЕРФЕЙСОВ ИСПОЛЬЗОВАНИЯ всех возможностей параллельных конкурентных процессов расчетами (не транзакциями). М.б. я ошибаюсь, но приведите мне контрпример. Чтобы можно было извне программно управлять приоритетами, блокировками, сообщениями да еще и гарантированно не подвесить при этом сервер БД.

Эээ... Не совсем понятно, о каких "ОТКРЫТЫХ ИНТЕРФЕЙСАХ ИСПОЛЬЗОВАНИЯ" Вы ведете речь? Блокировками, сообщениями и "подвещиваниями" можно управлять, например, в MS SQL. Если речь дополнительно заходит о приоритетах отдельных процессов, реализуемых на уровне движка - смотрим в сторону СУБД, которые это поддерживают (например, Oracle).

СисойIscraFM верно привел пример с гетерогенными системами. Я тоже видел в работе систему, работающую с единой бизнес-логикой одновременно с СУБД 2-ех типов.

И какие проблемы построить гетерогенную систему в классической двузвенке с использованием СУБД, которая в своем функционале имеет возможность работать с гетерогенными данными (например, MS SQL)?! Для конечного пользователя обращение к гетерогенным данным будет ПРОЗРАЧНО, ибо он будет обращаться к ОДНОЙ СУБД, при этом не имея понятия, где и в каком хранилище находятся данные, к которым он обращается. Более того, смена гетерогенного источника (например, с Access на другой источник, поддерживающий стандарт ODBC или OLE DB) может даже и быть не замечена клиентом.

СисойДа и сами по себе мультиСУБД-шные ERP (когда в один момент времени БД одна, но возможна "холодная" замена) появляются от потребностей производителя как можно с наименьшими затратами обслужить максимальный объем рынка.

Вам часто приходилось менять в ERP системе с апп. сервер, скажем MS SQL на Oracle? О то ж... Применимость таких систем с возможность работы на разных СУБД - выбор типа СУБД только на этапе приобретения\внедрения, но никак не во время работы продакшена. Но, опять всплывают маркетинговые аргументы в чисто техническом обсуждении.

СисойЕще один нюанс - лицензии на сервера приложений во многих системах дешевле, чем на сервера БД (при массовой закупке). Вот и думайте, где распараллеливать.

Конкретный пример расчета можно увидеть? Не забывая про стоимость лицензий для СУБД.

мод pkarklinА так, скока мы бы апп. серверов не поставили рядом с одним сервером СУБД узкое место все равно останется в последнем, ибо данные на нем.
так и я об том же - это узкое место надо разгружать, т.е. вычисления циклы и прочее относить на аппс. большие системы так и устроены.

Следуя Вашей логике разгрузить ОДИН СЕРВЕР можно только установкой ВТОРОГО СЕРВЕРА. Вам не приходило в голову, что дешевле\проще\технологичнее иметь ОДИН БОЛЬШОЙ И МОЩНЫЙ СЕРВЕР или КЛАСТЕР?

СисойЯ дважды в реальных внедрениях на предприятиях переходил от MS SQL к Oracle. Ситуация простая: лицензии MS SQL уже были (местная АСУ), поэтому пилотный проект и продуктивный старт делались на этой СУБД. А тиражирование на холдинг выполнялось уже с использованием Oracle. Обычный метод опционов: минимизация затрат до получения ощутимых результатов.

И где же здесь именно ПЕРЕХОД?! Вы в одном месте использовали одну СУБД, а в остальных другую. Теперь этой организации, надо держать специалистов по двум СУБД? Или все-таки MS SQL был полностью исключен? Т.е. вложенные в него средства были похерены? Задлянафига?

СисойНе совсем понятна привязка серверов приложений к СУБД. Пусть у нас есть 1 процессорная лицензия на SQL или 50 пользовательских. Какая разница - использую я их с одним сервером приложений или с несколькими? Важно лишь соотношение цены лицензий.

Я Вас не про привязку спрашивал. А про сравнение стоимости лицензий только на СУБД (для 2х звенок) по сравнению со стоимостью лицензий на СУБД + стоимость лицензий апп. сервера (для 3х звенки). Разницу чувствуете?!

СисойКроме того, на рынке есть достаточно много СУБД, не поддерживающих кластеризацию единой БД (и систем на их основе). Масштабировать систему в этом случае можно только серверами приложения.

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

iscrafmя думаю, что конструктивней будет, если противники использования СП выскажут аргументы почему СП является рудиментом. И чем он мешает или в чем проигрывает по сравнению с вариантом когда он отсутствует. плз

А разве мои ответы на приписываемые N-звенкам "фичи", не являются аргументацией классической двузвенки?!