Uridian \r
Скажем так, если все вышеперечисленные сладкие слова реально только усложнят проект без обоснований их использования ( у Вас четко под проект определена одна СУБД, не планируется с ним одновременная работа тысяч удаленных пользователей и т.д. и т.п. ), то мое личное мнение - бизнес логике самое место на СУБД. Если проект еще не начат и Вы решитесь писать по такой схеме, то позволю себе порекомендовать обратить внимание на кроссплатформенную СУБД Sybase Anywhere Studio 9, который будучи совместимым на уровне TSQL с MSSQL имеет еще собственный диалект WatcomSQL и встроенную поддержку Java, что обеспечивает реализацию на сервере бизнес-логики любой сложности, сервак может включаться в инсталяцию приложения, не требует администрирования, довольно таки много умеет, включая лучшую из существующих репликацию с любыми СУБД и поддержку мобильных устройств и очень дешево стоит. Во всяком случае если приходят в голову мысли насчет бизнес-логики на сервере, то на ASA поглядеть точно стоит, на Sybase.com выложена бесплатная девелоперская полнофункциональная версия, можно также посмотреть и на диалект WatcomSQL, хотя бы с примеров скриптов: статья 1, статья 2 и ознакомиться на счет различий в TSQL между MSSQL2000 и ASA9 .

Также необходимо взаимодействие с рядом стоящей системой управления (Галактика, если кто знает такую), работающей на MSSQL, поэтому, для того чтобы не плодить СУБД и техперсонал, другие СУБД не рассматриваются
Вы немножно ошибаетесь - ASA прекрасно работает с MSSQL, может использовать его в качестве Remote сервера, и репликация ASA позволяет полноценно работать с СУБД от MS, Sybase и Оракл.

Хотелось бы узнать о практических примерах использования именно TSQL для написания БЛ, или попытках его использования. Насколько я понял из твоего ответа, у тебя опыт был отрицательным.
Нет - опыт был положительным, расчет ЗП изначально реализовывался на TSQL и его функциональности вполне хватало. Другое дело, что когда я перевел проект на ASA, то получил расширенную функциональность и переводя проект на WatcomSQL я существенно подсократил обьем кода, облегчив его сопровождение, читабельность, скорость выполнения и кол-во возможных ошибок (как говориться чем меньше кода, тем меньше ошибок), плюс кое что перепроектировал для критичных мест, где дополнительные возможности ASA позволяли все организовать более эффективно, просто и красиво, ну и избавился от некоторых ограничений MSSQL, которые приводили к "танцам с бубном". Так что основная причина перевода проекта с MSSQL на ASA была не "бедность" TSQL, а нетребовательность ASA к аппаратным ресурсам, встраиваемая СУБД (включается в инсталяцию), отсутствие администрирования, высокая скорость и надежность, развитые средства управления (вплоть до консультанта индексов, профайлера ХП и отладчика с возможностью выполнения во время отладки запросов), взаимодействие с СУБД других производителей, низкая стоимость и гибкая лицензионная политика Sybase. Кроссплатформенность для данного проекта значения не имела. В принципе все вышеперечисленное было критично к проекту, который является тиражным, а значит планируется распостраняться по удаленным клиентам и сети диллеров.

Ну а насчет опыта использования TSQL - для бизнес логики я считаю его хватает с лихвой, на самом все будет зависеть только от правильного проектирования БД и использования методик обработки и расчетов информации.

grGuest
Я приверженец 3-х звеньев, ибо бизнес логику легче реализовать на более развитых языках (я использую Delphi). Но это не исключает использования T-SQL для манипуляции с данными, на "самом низком" уровне.
Извините, но не согласен - чем это Delphi более развитый язык по сравнению с тем же TSQL в области управления и манипулярования информации ? Работаю в нем 8 лет, но что то такого не заметил, наоборот в Delphi я бы сказал наблюдается определенная и досадная ограниченность в этом плане. Давайте уж тогда определяться, кто как воспринимает термин "бизнес-логика". Если у Вас нейросетка в бизнес-логике используется для прогнозирования или обработки сложной информации (отпечатков пальцев например), не ложащейся на релляционную модель, то как говориться в добрый путь, используем встроенные Java обьекты в РСУБД, если платформа позволяет или выносим логику на тот же Delphi, если не позволяет. Но опять же не всю, а только ту, которая не реализуется или не эффективно реализуется средствами РСУБД, зачем из за частного усложнять общее. Ну а если Вы бух. учет на бизнес-логике реализуете, то для меня это всегда означает только одно - SQL вы знаете на уровне "select * from table where <Condition>" и никакие доводы о "превосходстве" высокоразвитых языков по сравнению с SQL меня не убедят, лично делал запросы, которые одним махом подоходний и ЕСН считают, с учетом нарастающих с начала года, вычетов, налоговых шкал и т.д., не самый простой расчет вообще то. Еще кстати могу указать на множество удачных примеров сложных расчетов на TSQL - расчет потребления электроэнергии по схемам подключения (чистой воды графы), расчет кварплаты, и т.д.

Моя бизнеслогика предпологает объектную модель сущностей и взаимосвязи между ними, что очень красиво ложится на настоящие, "жизненные" процессы,
Я считаю, что на ООП можно конечно красиво описать модель, приближенную к реальной (но опять же только приближенную), однако так же считаю что на ООП не получится красиво работать, обьекты это конечно хорошо, но в основном то нас интересует обработка множеств, а не отдельных обьектов. Не спорю - ООП это круто, на нем можно красиво и быстро лепить интерфейс, свои компоненты, трансляторы, плагины и еще кучу полезных вещей, хоть операционки, но не в данном контексте. Кстати любое РСУБД позволяет скрывать от клиента способы хранения информации на низком уровне посредством вьюверов и ХП, организуя для него простую и наглядную модель доступа и обработки информации. У меня например учет табельного времени спроектирован и храниться в виде отклонений от планового времени, но клиент видит и работает с полноценным табелем, как будто бы он весь хранится в таблице, даже не подозревая, что добавляя в табель новый показатель он на сервере вызывает на самом деле операцию удаления записи. Эта структура эффективно работает, так как отклонений от плана на самом деле не больше 10% в месяц и храня в таблице эти 10% вместо 100% я не раздуваю размер БД и увеличиваю скорость обработки запросов к данной структуре.

На T-SQL такое, пока (до Yukon`а), не реализуемо.
А разве на Yukon будет изменен TSQL ? Что именно на нем такого нового появиться ? (я просто не в курсе с тех пор как ушел с MSSQL, надоело честно говоря ждать "подачки" решений от MS, которые уже как много лет давным давно реализованы у конкурентов и никому их за революцию, кроме как программистам, работающих на MS платформе выдать сложновато - засмеют ведь и расскажут, что все это у появилось давным давно, еще в 90-х). Кстати, если Вы надеетесь хранить обьекты .NET на СУБД, то могу огорчить сразу, уже давно есть такие полноценные решения в Оракл и Sybase, в которых можно Java класс цеплять на поле таблицы. Не заметил я, что без особых случаев этим кто то пользуется. В данном случае такую фичу следует воспринимать и работать как с BLOB-ом и использовать для хранения некоторой дополнительной сложной информации, но не более того, так как оптимизатор в стороне остается, когда в запросах на поля классов условия идут, да и распаковывать/упаковывать обьект для каждой записи в поле тоже драгоценной время занимает, я уж молчу про обеспечение целостности средствами сервера, репликацию таких обьектов и т.д.

grGuest
А как быть с документооборотом, где документы разделяются по типам (разным структурам таблиц, меняющихся со временем), а экземпляры документов по алгоритмам использования, на основе тех данных которые в них хранятся, и метаинформации о них которую TSQL не может использовать.
А версионность объектов: время-независимая часть объекта (1 таблица) и время-зависимая часть объекта (столько таблиц сколько раз корретирвали стуктуру объекта) + данные в них и все это динамически в процессе работы системы, да плюс алгоритмы работы тоже версионны.
Вроде как в начале топика давали ссылку на топик "Система с изменяющимися алгоритмами расчетов". Так вот как раз там и описывается как реализовано на SQL, все то, что вы перечислили, вплоть до сложной обработки обьектов с различной структурой, поддержки наследования обьектов, хранения обьектов во времени и версионности алгоритмов даже задним числом :)

"А разве на Yukon будет изменен TSQL?" - Да + интеграция с CLR
Насколько я понял интеграция на уровне подключаемых extended procedure, И чем это может помочь ? И сейчас можно спокойно писать на MSSQL такие процедуры на VC и даже работать с OLE серверами из TSQL, не думаю что это слишком часто кем то используется, опять же только в достаточно неординарных случаях. Думаю с .NET будет та же ситуация - кому будет охота кушать ресурсы от сервера вызовом .NET, когда все прекрасно и на TSQL ложиться.

Наверное как всегда с сего обсуждения можно сделать уже известный и набивший оскомину всем вывод - "кто что знает, тот на том лучше и пишет". Нет смысла говорить, что вот так круче, чем вот так, всегда найдется специалист, который докажет неправоту утверждения. Я лично в последнее время предпочитаю утверждение "А вот так легче". Считаю, что чем меньше обьем кода, чем больше в нем только "чистой" бизнес-логики, без реализации вспомогательных решений ее исполнения, тем легче, а значит для меня и лучше. Процедуры на SQL весят копейки, алгоритмов в них тоже особо нет - вся реализации обработки данных полностью поддерживается самим СУБД, наше дело только на запросах говорить, что хотим обработать и получить, реализуя логику на SQL мы сразу получаем его в качестве встроенного в приложения скриптового языка, позволяющего быстро и динамически расширять функциональность задачи. Ну и плюс встроенная бизнес-логика в саму СУБД открывает большие горизонты - динамические он-лайн расчеты по требованию, кэширование (денормализация) информации с сложной структурой хранения для ее использования, придает БД цельность и независимость от внешних процессов - всегда приятно в ISQL написать EXEC sp_Calc и махом выполнить сложный расчет зп, заодно сразу проверив профайлером ХП узкие места в расчете, консультантом индексов проверив правильность использования оптимизатором запросов индексов и если где странные ошибки пошагово дебаггером их найти (а это кстати ценная фича, одно дело синтаксическая или логическая ошибка, а другое дело ошибка при манипуляциях множеств данных, тут обычный деббагер не поможет, нужен такой, который позволяет внутри отлаживаемой сессии выполнять запросы).

P.S. Вы извините, но я Вас немного подправлю - TSQL - это транзакт-язык запросов, а Delphi ООП алгоритмический язык, не надо Delphi называть языком высокого уровня, а TSQL низкого, а то выглядит странно, можно подумать, что я на TSQL команды управления процессором катаю :)