OLAP - все что нужно для финансового и аналитического анализа. Как раз из разряда высшей математики:
http://www.sybase.com/content/1037447/olap.pdf
Далее - если чего то не хватает, в СУБД расширенные хранимые процедуры никто вроде не отменял. Пишем на Си, подключаем, пользуемся.
Далее - своя метаструктура в БД описывающая нужную модель бизнес-логики, процессы, разбитые по ХП, динамический SQL для сборки по метаструктуре и ХП нужных алгоритмов выполнения и имеет на борту мощный универсальный движок. Соотвествующе в качестве языка имеет мощный язык хранимых процедур, на котором легко писать, нет нужды озадачиваться доступом к данным в БД, легко компилировать, при желании хранить нужные скрипты в метаструктуре и через динамический SQL быстро производить сборку нужных скриптов или компиляцию типовых ХП.
авторнашёл в книжном магазине пару интересных книжек по пострению 3-хуровневых систем, которые меня ещё сильнее убедили в такой необходимости.
Было бы конечно странно, если бы они разубедили. Может быть теперь купить и почитать пару книжек, наоборот описывающих плюсы и ньюансы двухзвенных приложений и критикующих 3-х звенки ?
авторДа и вряд ли покупатели захотят быть "заперты" в одной, пусть и очень сложной СУБД
А вот это миф 3-х звенок. Ни один сервер приложений не сможет обеспечить одновременную ровную работу блокировочника и версионника на больших нагрузках. А если вспомнить все мощные отчетные системы, обожающие SQL, так вообще этот фактор оказывается большим костылем для 3-его звена, лично сам не раз наблюдал эту картину. В любом случае, будет ли 2-х звенка или 3-х звенка, придется для разных СУБД, пусть и имеющих одинаковую структуру, вести собственные запросы, оптимизированные под конкретную СУБД (для некоторых еще и под каждую версию) и скрипты бизнес-логики. А где и как удобнее хранить такие скрипты, не озадачиваясь правами доступа и желая легкость их вызова - правильно, в хранимых процедурах - название само за себя говорит. Так же не вижу ничего страшного в том, чтобы запереть покупателя в пределах одной СУБД, если у нее будет низкая стоимость покупки, владения и сопровождения и нормальные интеграционных механизмы для обеспечения интеграции с другими продуктами и СУБД у покупателя.
Таким образом лично для меня 3-е звено и попытки впихнуть ООП в релляционную логику остается загадкой природы. Я в своей жизни кстати не встречал 3-х звенщиков, которые бы могли похвастаться глубокими познаниями в РСУБД, вот Java, C и ООП они знали прекрасно - это да. Сам я лично тоже балуюсь по мере надобности COM-серверами и технологиями распределенного доступа в нужных мне направлениях, но как то ни разу мне применить эти знания для построения 3-х звенной архитектуры мысли такой не возникало, все решалось стандартными средствами, где в БД помимо самих данных на себе описывала и хранила модель и процессы бизнес-логики, а клиентские приложения только вызывали нужные ХП и занимались своими основными задачами - построением для пользователя удобного и адекватного интерфейса.
