anvanoВидимо у вас такой проект, в котором не требуется
1) Десктопный клиент
2) WEB клиент с точно такой же функциональностью
3) Android клиент, который реализует основные функции приложения
4) iOS клиент, который полностью аналогичен андроидному
5) Вторая версия десктопного клиента специально для техсаппорта, реализующая фичи, недоступные ни в одном из вышеперечисленных, но при этом сохраняющие общий с ними функционал

Я в полнейшем замешательстве. Это что за такая СУБД, которая работает на всех указанных платофрмах, при этом позволяет содержать одинаковую программную логику (уровня T-SQL/PL SQL)?

anvanoВот когда вам потребуется при изменении логики какого-то функционала переписывать ПЯТЬ клиентов, вместо того, чтобы поправить один пакет в базе - тогда и посмотрим, моветон логика в БД или не моветон.

Бред. При чём тут вообще клиент?

anvanoТак что у нас наоборот, за логику в клиенте руки отрывают :)

Интересно, а чем программный код у вас пишут, ногами? Задницей? Трудновато наверное без рук-то.

anvanoПлюс запрещая держать логику в БД для, например, Oracle - вы автоматом выбрасываете на помойку половину функционала БД.

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

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

Собственно вести дискуссию на эту тему считаю бессмысленным. Не вижу ничего плохого в наличии T-SQL/PL SQL и прочих скриптовых плюшек в крупных СУБД, часто они могут быть довольно полезными и нужными, но со стороны качественной разработки серьёзных программных продуктов, бабки несущих, программная логики на стороне БД должна быть выпилена, а за попытки туда сунуться, отстрел на месте без суда и следствия.

anvanoДля хранения обычных табличек можно взять гораздо более дешевую в лицензировании базу.

Глупый и наивный бред, уж извините. Ниче тупее в жизни не слыхал.

anvanoВидимо у вас такой проект, в котором не требуется
1) Десктопный клиент
2) WEB клиент с точно такой же функциональностью
3) Android клиент, который реализует основные функции приложения
4) iOS клиент, который полностью аналогичен андроидному
5) Вторая версия десктопного клиента специально для техсаппорта, реализующая фичи, недоступные ни в одном из вышеперечисленных, но при этом сохраняющие общий с ними функционал

И да, забыл сказать, у нас на сегодняшний день таких продуктов даже не одна штука, успешно проданных за очень не смешные деньги. В последнее время успешно осваивается рынок продуктов на WebGL. При чём тут логика в БД -- в упор не пойму.

anvanoИ как перечисленное связано с поддержкой бизнес-логики в 5 клиентах под 4 различных платформы, написанных на 4 различных языках программирования? Реализация даже детально проработанного алгоритма на другом ЯП неизбежно сопряжена с вероятностью появления ошибок. Так зачем реализовывать одно и то же на 4-х языках, если достаточно реализовать в одном месте - в БД ?

У вас что, все клиенты напрямую с базой данных общаются?

АнатоЛойhVostt, о каких таких артефактах речь?

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