энди1) Сложнее - если система построена на xp то это посути 1 звено бизнес-логики, в случае использования еще и апп сервера перед ними надо писать еще код на апп сервере по задействованию хранимок. Т.е в данном случае апп сервер лишь усложняет ситуацию.
Я полагаю, что даже при использовании сервера приложений все равно должны использоваться хранимые процедуры.
Код по задействованию этих процедур на сервере приложений — рутинный (если не вовсе автогенерируемый).
Объем программного кода, реализующего логику системы СЭД, можно условно считать одинаковым для двух- и трехзвенных систем. Для трехзвенной системы к этому коду нужно будет добавить взаимодействие с БД, но это задача достаточно типовая и несложная. Зато задача разделяется и разработкой этих отдельных задач могут заняться более узкоспециализированные специалисты. Столь же квалифицированный, но более универсальный специалист скорее всего будет дороже.

эндиВ общем ляпнул не подумав, и забыв добавить IMHO :)
ИМХО каждый раз добавлять ИМХО — избыточно.

defecatorНо если хочется сокетов и иже с ними, то для СУБд есть такая штука, как external procedure - пиши собственную DLL, подкладывай её в СУБД и используй из неё. У меня так написана работа с COM Port прямо из Оракла. Ну вот захотелось мне так.
Разумеется это можно сделать.
Но это скорее всего дороже, чем просто использовать COM-порт на ЯП общего назначения.

schiСтесняюсь спросить, каким боком интеграция с внешней периферией и генерация PNG связана с базой данных ?
Они не связаны с базой данных.

эндиОпять же если мы говорим о транспорте до клиента и хочется компрессии да шифрования, пользуем openvpn.
VPN не поможет в случае компрометации рабочего места.
У клиента есть доступ к БД и у потенциального злоумышленника он тоже будет.
В случае трехзвенной архитектуры для доступа к БД необходимо получить доступ к серверу приложений, а его можно защитить надежнее, чем рабочие места клиентов.