Заведи сервер-прилоржений (middle tier) :) Почему обязательно должна быть двухзвенка .

Сервер приложений ? Ну это тоже самое что и middle tier :)

На самом деле в инете куча материалов по этому делу.

Ну если коротко и сбивчиво то так: почему стоит ограничиваться двухзвенной архитектурой (сервер - клиент), почему нельзя зделать третье звено, четвертое, n-ое (n-tier) ? Мы так далеко не пойдем, а остановимся на трехзвенке. В данном случае схема взаимодействия будет выглядеть следующим образом (сервер - middle-tier - client). То есть, есть клиент (он кстати может быть толстым - GUI и тонким - web-интерфейс) - пользователь что-то выбирает и жмет клавиши. На основе этого клиент посылает middle-tier информацию о том, что пользовател ввел то то и то то и нажал то-то и то-то. Или попросту говоря вызывает какой нибудь метод этого среднего звена. Способов реализации этого до фига и многое зависит от того, на каком языке ты пишешь. Это может быть сделано и на основе Sockets, и на основе DCOM, и на основе MIDAS (в Delphi и Builder'е) точно. Middle-tier обрабатывает полученную информацию, проверяет ее и посылает запрос в БД, БД возвращает набор данных на middle-tier, а middle-tier возвращает данные клиенту.
Таким образом мы можем получать очень легкого клиента (практически один интерфейс), и сравнительно мало загруженный сервер баз данных. Плюс к этому вся логика у тебя сосредоточена на middle-tier (на одном компе) и в случае изменения функциональности тебе будет достаточно изменить файла на этом компе. Плюс множество дополнительных полезных фич, таких как кэширование на middle-tier возвращаемых наборов данных и т.д.

>> могу добавить к выше сказанному что middle-tier можно расположить на другой машине...
т.е. вы можете распределять ресурсы(нагрузку)....

Я это и подразумевал. При увеличении нагрузки на middle-tier вы можете как увеличивать характеристики машины, так и завести под это дело еще один комп. То есть, часть клиентов у вас будет коннектится к первому компу из middle-tier, часть ко второму. А каждый из них будет работать с одним и тем же SQL Server'ом.
Если пойти дальше, то можно сделать такую штуку - перед коннектом клиента к middle-tier он оценивает(запрашивает) загрузку как первого компа принадлежащего middle-tier, так и второго и уже на основании этой информации решает к кому коннектиться.

Есть только здесь одна тонкость, которая портит мне всю жизнь :) В случае с middle-tier SQL-Server считает, что к нему коннектится один клиент (middle-tier) (хм. мы еще и экономим на лицензии :). При этом, если возникают блокировки, то мы уже не можем определить кто конкеретно из клиентов вызвал эту блокировку. SQL Server показывает на middle-tier, а вот дальше проследить источника проблем мы уже не можем.... :(

>> Спасибо, что ввёл в курс дела, будем изучать MIDAS

Работал с ним в Дельфях - там все очень хорошо и красиво реализовано. Кажется по Midas у меня была неплохая документация, так что если тебе нужно - напиши, я вышлю. :)

>> при правильной реализации - можно отследить....

Вот это уже интересно. Каким образом ?

Жизнь себе, я все равно не облегчу, так как наше middle-tier реализовано не нами, а мы можем его лишь слегка модифицировать. Но все равно очень интересно.

Так человек, спросил, как будет лучше. Никто и не говорил, что невозможно.

>> И не надо огород городить с МИДАСОМ (конечно классная полезняшка) - он полохо кончил, или почти.

Ну это еще не известно, а потом MIDAS это еще не весь middle-tier. Или DCOM тоже близок к кончине ? :)

Могу привести еще один плюс трехзвенки - независимость от сервера баз данных. При грамотно написанном среднем звене, я могу работать как с SQL Server'ом, так и с Oracle не меняя приложения. В принципе я так и делаю.
Хотел бы я посмотреть, как вы будете переносить все триггеры и хранимые процедуры с MSSQL на Oracle. Опять же, не говорю, что это не возможно, но зачем, когда можно решить эту проблему меньшей кровью.

>> А Вы что, триггеры и хранимые процедуры вообще не используете при трехзвенке? :) А зачем Вам тогда SQL Server, на dbase все также будет ))))

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

>> а все другие случаи - это так, для красоты и самовыражения. :)

Как сказать. Если каждый день мы дописываем ту или иную часть в приложении, то возвожность заменить на одном копмьютере middle-tier не меняя клиентов мне уже не кажется пустяком. :)

>> Ну что-то мы уже не в ту степь пошли, человеку то другое надо было :)

Соглсен, но вопрос был задан соответствующе. :)

Решая вопрос о том, где проверять корректность данных нужно учитывать множество факторов, например таких как для чего предназначена система, как и гед ее собираются эксплуатировать, она для себя или на продажу, сколько будет пользователей и как интенсивно они будут работать, будет ли нужен доступ через интернет и т.д.
Не сформулировав все эти требования человек в ответ получает лишь общие соображения и рекомендации :)