Если с технической точки зрения, то логику надо помещать как можно ближе к данным.
Тогда меньше вероятности что туда кто-нибудь вклинится обойдя проверки или заново реализуя алгоритмы. Плюс можно применять наиболее эффективные методы обработки - оптом, используя все фичи выбранной СУБД.
А вот по деньгам тут все не так однозначно.
Во первых процессор на сервере СУБД совсем не то что процессор на сервере приложений, тут и экономия на лицензиях и нелинейный рост стоимости после определенных значений.
Во вторых разработчиков на Java, .NET и т.п. больше и стоят они дешевле (при одинаковой квалификации) чем специалистов в SQL (TSQL, PL/SQL)
В третьих чем меньше приложение завязано на СУБД тем легче его портировать и шире клиентская база.
В четвертых поддержка изменений только приложения проще чем приложения и базы (причем не в два, а в четыре раза)

Так что где лучше сильно зависит от внешних условий.

JaneKate просто в базе нужно будет хранить файли результатов анализовЗачем в базе
JaneKate все остановится из-за такого ограниченияТогда и деньги найдутся быстро
JaneKate в сторону жарптицыКогда такое пишут монстры типа Dimitry Sibiryakov или kdv это одно. Я верю что они свою СУБД загнут любой буквой зю и выйдут из любого штопора. А вам я посоветую или заключить с ними договор или пойти более натоптанной дорожкой.
JaneKate RLS, нужно будет делать самомуRLS вам не нужно. Вы не совсем понимаете что это такое. Нужна вам скорее всего обычная модель безопастности (пользователи, роли, объекты, разрешения ролям на объекты), но это уже другая тема. (Я не знаю умеет ли FB роли как группы пользователей)

JaneKate это Вы имеете в виду SQL Server?Я имею в виду базу которую вы лучше знаете. То есть программу действий если что либо будет работать не так как ожидалось
У скуля пользовательская база шире, вероятность наткнуться на неизвестный баг меньше. Связываться с FB (при всем моем уважении к разработчикам), особенно если вы ее не знаете, без поддержки - экстрим еще тот.
Но безумству храбрых поем мы песню (с)
JaneKate держать там администратора SQL Server'аА FB типа администратора не требует, устанавливается сам и работает всегда. Пользователи тоже сами заводятся, патчи скрипты тоже сами накладываются, с производительностью проблем никогда не бывает и из бакапа никогда не надо будет восстанавливаться.
JaneKate но для этого нужны дополнительные работы (в плоть до FTP-сервера).Зачем? В простейшем случае расшарьте папку.
JaneKate По поводу RLS, возможно Вы правы, я не доконца понимаю ROW level security - организация доступа на уровне строк - то есть эту строку показываем эту скрываем. Это отличается от АНСИ доступа на уровне столбцов, которые выполняются во время парсинга запроса. Зачем вам такие сложности непонятно.
JaneKate Программирую на C#, по-этому, в свете новых веяний решил использовать ОРМ-систему - EF. Вот только думаю, что реализовывать на сервере, а что на клиенте.Хотите бесплатный совет - реализуйте ВСЕ на сервере - клиент только отображает результат хранимых процедур и перечитывает набор данных (или обновляемую строку)

ViPRos Блин, ну что за огульные советы - все на серверетрехзвенкой ТС не увлекается, я ДБА, коробочных приложений никогда не делал, какой еще совет я могу дать?

JaneKate так как БД действительно более расчитана на пользователяА это здесь причем?
JaneKate к тому же, используется ОРМ-система, то возможно и проще реализовать разумную часть бизнесс-логики в приложении.Реализовывайте где хотите, слабые места логики на клиенте озвучены.
JaneKate Почему Вы так насторожено относитесь к связке жарптици и EF? Действительно ли там так много проблем?Я довольно давно работал с FB (версии 1 с копейками) и совсем не работал с EF, про проблемы не слышал, но аргументы вы приводите довольно сомнительные.