Можно что угодно делать - писать тиражные продукты или под себя, пытаться экономить трафик (интересно как это можно сделать, перенося логику проверок и расчетов на клиента), делать еще что то - но есть очень важное правило - целостность, правильность и непротиворечивость данных должна быть гарантирована на уровне сервера. И точка. Иначе потом приходится видеть программы, где сальдо противоречит приходу и расходу, где в таблицах лежат данные, которых просто быть не может. Я всегда делаю просто:
1. Сервер последняя инстанция - вся логика проверок и расчетов лежит только на нем. Так же это правило гарантирует защиту не только от ошибок юзеров, но и от ошибок в клиентском приложении, т.е. от кодеров и является для них тестом на корректность работы клиента.
2. В клиентское приложение встраиваю только логику проверок и только в рамках правил, что эта логика во первых не усложняет код клиента, во вторых не дает нагрузок на сервер, в третьих позволяет сминимизировать откаты транзакций, т.е. неудачных сохранений. В остальных случаях, если хотя бы один пункт нарушен, я отдаю проверки на сервер, таким образом экономя время разработки клиента и его стоимость разработки сопровождения.

P.S. Ну а насчет трафика - что то я не очень понимаю, какой такой трафик ? Юзеры что, со скоростью миллион записей в секунду данные вносят ? Получили набор данных, провели все нужные изменения в режиме отложенных изменений, в рамках транзакции сохранили все изменения. Трафик на сессию минимальный. У меня лично клиентские приложения вполне спокойно себя чувствуют при работе с удаленными серверами через GPRS посредством интернета, с включенным режимом криптографии и сжатии протокола на СУБД.

Серега ASCRUS
Не все действия с БД влияют на целостность. Например несложный расчет чего либо может лопатить пол базы и выдавать одну страницу отчета. Тут прямая дорога выполнять это на серваке.
Для другого отчета требуемой информации может быть примерно столько, сколько и выдаваемой, но сам расчет трудоемкий. Я не вижу причины, что бы не забрать инфу с сервера на клиента и крутить там сколько вздумается не мешая остальным.
Если логика не влияет на целостостность данных - те же отчеты, то они и должны крутиться на клиенте. Здесь сервер участвует ровно настолько, чтобы клиентское приложение не замучало его серией запросов - легче написать одну ХП, чем для подготовки данных для построения отчета посылать серию запросов на сервер, которые не только влияют на производительность и нагрузки сервера, но еще и такие важные вещи, как блокировки в зависимости от уровеня изоляции. А вот все остальное должен делать исключительно клиент - было бы дико пытаться на сервере построить тот же кросстаб, вместо того, чтобы отдать это на откуп отчетнику.

Cat2ASCRUS.
Целостность и непротиворечивость - священная корова. И разумеется ее должен обеспечивать сервер. Но есть и другой род ошибок пользователя - недопустимые по бизнес-логике значения. Многие из них можно, и на мой взгляд нужно, отлавливать еще на клиенте. Допустим, моя прога введена в эксплуатацию в 2005 году. Следовательно даты текущих операций могут быть не менее 20050101 и не более сегодняшнего дня. Почему бы это не проверить на клиенте? Что бы юзер не ввел дату 01.01.0200. Причем эта дата вполне корректна и никак не влияет на целостность и безопасность.Или если юзер не ввел обязательного значения, то это ему вполне может напомнить клиент.
Пожалуйста, я только ЗА - если проверка даты текущих операций не повлечет за собой сложные или частые запросы на сервер, пусть клиент проверяет. А вот если повлечет, то сервер по любому проверять будет - не стоит его дважды загружать одной и той же работой, которая сказывается на ресурсах, производительности или блокировках. Ну а проверить корректность даты, обязательное поле, сделать Lookup, чтобы клиент не мог внести неправильного FK и прочее - это локальное и само собой разумеющееся, странно было бы видеть клиентское приложение, которое бы этого не делало, тут даже интернет-приложения стараются следовать этим правилам, хотя это и усложняет разработку на том же PHP из за ввода в HTML проверок на JavaScript и я считаю это усложнение в таких случаях оправданным.