Бизнес-логика на T_SQL - стоит ли

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

А какой вариант быстрее?
Для MSSQL процедуры - самое быстрое (буквально) средство
но вот с гибкостью и, что немаловажно, с поддержкой...
Еслт процедур будет больше тысячи, то поддержка такого рода системы
становится нетривиальной задачей.

Не сомневайтесь ... Вам придётся всё-таки переносить логику на клиента. Зачастую заказчик требует обработку ввода сразу, а не при отсылке пакета данных на сервер. Это достаточно большое количество мелких запросов. М.б. решением для большой системы должно быть создание сервера приложения (DCOM ...)

К сожалению мелкомягкие до сих пор не реализовали триггеры 'before', так что действительно, проверку (или по крайней мере часть проверок) для ускорения совокупной работы системы придется выносить на клиента. Хотя идеология системы клиент-сервер - 'умный сервер' и максимально тупой клиент.

Фигня!
Хранимые процедуры быстрее, и гибче, и легче делать upgrade. Особенно проверки лучше доверять серверу. Во-первых ошибка на клиенте позволяет продолжать запихивать некоректные данные на сервер. Во-вторых обновить клиента с ошибкой на 20-...n машинах сложнее чем просто поменять процедуру на сервере. Конечно не надо ВСЕ вешать на сервер, типа правильный формат даты и пр., а именно бизнес-логику.
С уважением. AndyMandy.

На клиенте действительно легче реализовать логику. Процедуры на сервере работать будет несколько медленнее. И есть еще куча сложностей, которые выше перечислены. Но я бы всё равно рекомендовал как можно больше проверок делать на сервере. Почему?
Во-первых, гораздо проще изменить процедуру на сервере чем процедуру на клиенте. С одной стороны перекомпиляция SQL-процедуры, с другой - перекомпиляция проекта(а ехе-файл может быть не один) и замена его на рабочих местах.
Во-вторых, процедура на сервере "лучше знает" о том, что и как на нем храниться, можно будет менять(не сильно) структуру БД и исправлять немного процедуры, не меняя клиентскую часть.
В-третьих, если разработчик клиентской части не один - черт знает чего они там могут наделать.

С приветом Сергей

SQL 2000 имеет новый вид триггеров - instead of. Они выполняются вместо изменения, если всё ОК - то в конце дублируем исходное действие by inserted or deleted obj.

Вообще-то я имел ввиду другие проверки - т.е. мою конкретную задачу - может ли юзер войти, какой ему делать доступ, сколько времени ему можно работать, по какому тарифу это считать и т.п.

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

"У меня стоит дилема - либо перенести всю логику (довольно сложные проверки, вычисления) на SQL сервер в виде хранимых процедур на T-SQL и получить легкую настройку, либо запихать все это в свою программу на с++ ...."

Нет, никогда не было, и никогда не будет в системах клиент-сервер такой "дилемы" (либо всё на сервере, либо всё на клиенте). По каждой процедуре это решается ИНДИВИДУАЛЬНО. Поэтому что-то будет в виде процедур на сервере, а что-то на клиенте. Критериев для определения места выполнения процедуры может быть много (сложность логики, кол-во приложений, которые будут её выполнять, кол-во и сложность SQL-запросов в процедуре, скорость выполнения и т.д.). По мере приобретения опыта разработчик начинает интуитивно выбирать правильное решение. Но на первых этапах приходится каждый раз думать.