Требуется совет по поводу архитектуры.. Опции

[defnull]

Добрый день. Хотел бы посоветоваться по поводу архитектуры разрабатываемой системы.

Задача: есть сервер на котором крутиться PostgresSQL. Есть АРМ разных видов которые должны иметь доступ к данным бд на сервере и которые должны работать с базой параллельно. База данных должна бекапиться удалённо, и удалённо же должно производиться управление учётками пользователей. Проект выполняется с использованием QT на С++. Подключение к БД через qt модуль работы с postgresql.

Возникшие проблемы:
1) не до конца ясно делать ли серверную часть и насколько должны быть толстыми или тонкими клиенты.
2) не понятно какими средствами лучше всего бекапить удалённо базу и как управлять учётками.

Выявил несколько вариантов:
1) Без серверной части. То есть админ ставит БД, подключается к ней со своего (АРМ), заводит пользователей и те напрямую работают с базой.
Из плюсов - вроде бы простота реализации.
Из минусов - сложности контроля пользователей и проблемы с их блокировкой (например надо отслеживать работает ли пользователи в текущий момент с базой чтобы сделанный бекап не был противоречивым) Нельзя проконтролировать пользовательскую активность напрямую с админского АРМ (здесь и далее админская часть на его собственном компе а не на сервере)

2) Серверная часть как прокси. Тоесть клиент вначале подключается к серверной части а та пускает или не пускает его на работу с базой.
Из плюсов: учёт активности пользователей. Возможность заблокировать пользователя почти в любой момент.
Из минусов: Дополнительный расходы на сервер(по два соединения tcp вместо одного когда нет серверной части). Не ясно можно ли просто перенаправлять всю инфу с одного сокета в другой после того как мы пускаем пользователя??? (идея такая.. клиент авторизуется на сервере и тот далее подключается к бд под учётной записью пользователя и передаёт информацию от клиента к бд и от бд клиенту через себя)

3) Клиент проходит авторизацию на сервере а после если авторизация успешна напрямую подключается к БД. При этом от клиента идёт два соединения к Серверу и к БД. Сервер управлять клиентом (например послать запрос чтобы клиент разорвал связь с БД)
Из плюсов: учёт активности пользователей. Возможность заблокировать пользователя почти в любой момент.
Из минусов: Дополнительный расходы на клиента(по два соединения tcp вместо одного когда нет серверной части). Да и в целом схема мне кажеться несколько усложнённой..

А уж с бекапом вообще не ясно как быть. Условия таковы что нельзя использовать сторонние утилиты по резервированию/восстановлению, тоесть даже pgdump использовать по идее нельзя. А если всё же использовать, то надо писать обёртку... Но pgdump вроде бы здесь не подойдёт он ведь должен работать на той же машине где и БД.

Был бы очень признателен если бы кто-нибудь дал развёрнутый ответ что в данном случае предпочтительнее использовать..

[trdm]

Был бы очень признателен если бы кто-нибудь дал развёрнутый ответ что в данном случае предпочтительнее использовать..

Не понял юмора.
Предпочтительность использования варианта обычно определяют входные условия: бюджет, ТЗ, требования заказчика к системе.
Если что-то из этого пункта не ясно, заказчика обычно спрашивают.
По требованиям к системе все немного сложнее, но опросные листы поправят дело.
Как с этими вопросами дела обстоят?

так чего?

[defnull]

Система является учебным а не реальным проектом. В ТЗ не оговорена конкретная архитектура. ТЗ составляли мы сами, по всем правилам. Хотя теоертически по специальности написание ТЗ не входит в наши задачи нам пришлось его разрабатывать, и не знаю как там в реальных проектах, но мы сдавали ТЗ уже около 7-9 раз..
Фактически нам предоставляется возможность самим выбрать способ реализации. Оговорены лишь те аспекты что я перечислил, остальное на наше усмотрение. Так как должного опыта в этом нет то и спрашиваю совета, заодно хотелось бы избежать заранее подводных камней.

Да и можно использовать одно соединение с БД для всех соединившихся пользователей, но нужно ли.

Насколько я понимаю из поставленных перед нами задач требуется именно параллельная работа нескольких пользователей . Как я вас понял вы предлагаете делать всё через одного пользователя последовательно передавая запросы от разных клиентов. Такое не подойдёт=( Хотя никто не мешает делать и под разными пользователями с несколькими соединениями к бд.