Пользователь 2 процессора - 4 гига оперативки - вся база под 10 гиг - и тормозит - если больше 10 клиентов -
и что теперь - новый сервер покупать?

Обратный пример - самописная учетная система - типичная 2-х звенка, вся логика в хранимых процедурах, MSSQL, 600 одновременных пользователей, 300Gb база, 300млн. проводок, перелезли с 8хXEON700+8Gb RAM на 8xITANIUM2+8Gb RAM , потому что стало подтормаживать - теперь снова летает. Но, конечно, система вылизывалась достаточно долго.
Сервер масштабируется до 24 процессоров и 32Gb RAM, поэтому лет на 10-20 хватит.

При этом года 3-4 назад vs активно игрались с MTS и DCOM. Переписали основную бизнес-логику по проведению проводок на С++, оформили как DCOM объект под MTS, запустили на тестирование. Может, конечно, у нас руки росли не оттуда, но там, где справлялся 1 MSSQL-сервер нужно было ставить десяток MTS-серверов, чтобы добиться той же производительности при 300 одновременных коннектов.

ВМоисеевДмитрию Сорокину

На ТЗ взглянуть нельзя ?

С уважением, Владимир.

ТЗ? Их тысячи! Эта информационная система начинала создаваться в 1995г! на MSSQL 4.2.

Насчет MTS - вот, что тестировалось: Был написан СОМ-класс на С++ (насколько я помню - использовалась ATL, где есть готовый template для таких штук, но я могу ошибаться), в котором было 2 метода - подтверждение и отмена проводок. Логика была практически один к одному перенесена из аналогичных хранимых процедур. Конечно, совсем один к одному не получилось из-за отсутстыия в С++ таких вещей, например, как временные таблицы:), но вся логика и весь flow были сохранены. Класс регистрировался на MTC - серверах (характеристики машин сейчас не помню, вроде 2-х процессорные XEON 700 c 2 GB памяти) и проводились масштабные испытания - на тестовой базе тестовая программа открывет поток за потоком, каждый поток создавал инстанцию класса и проводил тестовые проводки.
На самом деле у нас стандартизирован набор разнообразных тестов - разные типы проводок, проводки сегодняшней датой, проводки задним числом и т.д. Потом меряется среднее кол-во проводок в секунду для возрастающего количества соединений. Вообщем, деталей уже не помню, но как мы ни вылизывали сишный код - результат был на порядок хуже прямой работы с MSSQL.

Потом мы пробовали просто создавать DCOM-обертки над хранимыми процедурами. Т.е. создается некий функциональный класс, в котором в виде методов описывались хранимые процедуры, а в коде методов эти процедуры вызывались. Результат был конечно лучше, чем вначале, но все равно хуже, чем при прямом использовании хранимых процедур - особенно на таких "быстрых" процедурах, как проведение проводок - там быстродействие доходит до сотен проводок в сек.
Но все бы ничего, и было бы интересно навесить "классовую" обертку на хранимые процедуры, но эта невозможность в MTS использовать т.н. stateful объекты! Т.е. значения свойств между вызовами объекта не сохраняются (чтобы их сохранить, надо было извернуться через одно место - либо использовать сессии, либо - таблицы БД либо сам придумай что), в результате чего подобные классы выраждаются в простые библиотеки функций, ничем не лучше хранимых процедур, т.е. ни о каком нормальном ООП в случае таких классов-оберток речи нет.
Может, конечно, в DCOM что и изменилось с тех пор - не знаю.

Теперь мы делаем что-то похожее на .NET - логика остается на хранимых процедурах, но создаются классы-обертки, генерирущиеся автоматом на основе метаданных о структуре и взаимосвязях таблиц, вьюх, хранимых процедур и т.п. Аналогично есть визуальные классы (для создания интерфейса, пока - win32), генерящиеся тоже на основе метаданных. на самом деле, это, конечно, не просто обертки - там и свой механизм локов и своя система авторизации и механизм раннего оповещения об изменении данных и свое кеширование и ..... Но бизнес-логика остается в хранимых процедурах.

Речь не идет о переносе бизнес-логики куда-то на средний слой. Речь идет лишь о том, что вместо набора таблиц, вьюх и процедур программист (а в дальнейшем и продвинутый пользователь) работает с классами, свойствами и методами, т.е. использует объектную библиотеку, являющуюся интерфейсом к БД. В принципе ничто не запрещает использовать эти интерфейсные объекты, например, при написании скриптов на каком нибудь vbscript или С# с последующим запуском локально или на некоем дот-нетовском scripting host. Типа - вот вам и сервер приложений...

Old NickНа данный момент у меня есть реализация этого механизма на Дельфи. Из интерфейса самой программы создаете метаданные, т.е. регистрируете класс, добавляете атрибуты, создаете методы с кодом на T-SQL, затем компилируете и получаете таблицы и процедуры и данный класс уже готов к использованию в системе. Интерфейс даже проектировать не нужно. Сам подхватывает все описания и предоставляет формы.
--------------------
Не учи отца и баста!

У нас несколько по другому. Уже существующие таблицы, вьюхи, хранимые процедуры и т.п. описываются в метаданных - поля - это свойства объекта, ссылки - это тоже свойства, но типа "объект", методы объекта - хранимые процедуры или откомпилированный .NET код (давай, вычисляй свои частные производные!). Можно создавать вычисляемые поля, составные свойства (типа структур - например валютная сумма и обозначение валюты), JOIN можно делать по нескольким полям, есть альтернативные ключи, и т.д. Плюс наследование и полиморфизм, плюс сам объект выступает не только как "одна запись" в БД, но и несет в себе методы навигации и интерфейсы, позволяющие ему работать как источник данных. Плюс свой транзакционный механизм - все изменения накапливаются, а потом одним махом сохраняются в БД. Плюс свои локи. Плюс своя security.
Для создания интерфейсов есть понятие визуализаций, которые тоже являются обладают всеми характеристиками объектов, и которые тоже описываются в метаданных (но можно и самим поизвращаться, сделав уникальную визуализацию). Пока разработана WIN32 визуализация, начали работать над WEB.

Кое что еще не доделано - надо доделать workflow, когда вводится понятие состояний объекта, в разных состояниях видны лишь определенные свойства и методы, и при этом различные методы в зависимости от их результата переводят объект в другие состояния (вообщем - почти конечный автомат). Не доделан механизм "раннего" оповещения об изменениях в БД (читай-серверные события) и механизм "кеширования" данных, когда лишь часть данных с сервера грузится на клиента, что очень важно для, например, WEB-интерфейса.

Вообще мы пытались построить полностью объектно-ориентированный интерфейс к БД со всеми аттрибутами ООП. ИМХО, такой подход позволяет достаточно быстро и, главное, с умом, создавать новые приложения и "рефакторить" старые наработки, когда существующая бизнес-логика и структуры просто описываются в метаданных.

Но все это не имеет ничего общего с общепринятой сейчас трехзвенной архитектурой и принудительного выноса бизнес-логики на средний слой. Да, при подобном подходе создается некая объектная оболочка над базой данных, но тут нет ничего общего с N-tier архитектурой SAPа или J2EEшных приложений.
Однако мне такой подход кажется более "приближеным к жизни", что-ли. Для меня главным преимуществом многозвенки является возможность "красиво организовать" свое приложение, работать не с таблицами и процедурами, а с объектами. Все таки (ИМХО) ООП по сравнению с классическим "функциональным" программированием имеет кучу преимуществ. Пусть за объектом стоят таблицы и хранимые процедуры - не важно. Важно, что наружу все это выглядит гораздо красивее. Плюс, что не маловажно - инкапсуляция (лучше иметь дело с объектом, чем с кучей хранимых процедур), наследование (есть объект - "клиент", создадим на его основе объект "поставщик"), повторное использование (уже есть объект "клиент", используйте его как справочник в своих приложениях, если надо - наследуйте от его базовой визуализации свою собственную). Плюс быстрота разработки...

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

Хотя все это ИМХО, и, возможно, мы изобретаем велосипед:)

Простой рабочий Дмитрий СорокинТеперь мы делаем что-то похожее на .NET - логика остается на хранимых процедурах, но создаются классы-обертки, генерирущиеся автоматом на основе метаданных о структуре и взаимосвязях таблиц, вьюх, хранимых процедур и т.п.
Хотелось бы по-подробнее - что из себя представляют классы-обертки.

Поподробнее - это надолго:) В приаттаченом файле (это глава "введение" из хелпа для программистов) - находится краткое описание функционала библиотеки BaseObjects, которая как раз и создает объектное представление БД. Кроме этой библиотеки есть еще библиотека VisObjects для создания визуализаций.