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

[defnull]

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

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

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

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

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

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

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

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

[ViGOur]

ИМХО, лучше использовать 2 вариант.
Минусы этого варианта это вовсе не минусы. Так как 2 соединения на пользователя это ерунда, а в передаче инфы с одного сокета на другой не вижу никаких проблем, сам реализовывал подобное в свое время. Да и можно использовать одно соединение с БД для всех соединившихся пользователей, но ну жно ли.

Вот насчет работы с БД я не могу ничего сказать, так как плохо знаю.

[trdm]

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

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

так чего?

[defnull]

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

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

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

[trdm]

Делайте толстого клиента, а сорцы публикуйте на гуглекоде или ассембле.
А я у вас потом буду подсматривать.
У меня самого такая задачка на очереди: http://code.google.com/p/unnstudio/
но это не учебная, а реальная необходимость для работы: задел на будущее под линукс.
по инструментам мы с вами совпадаем...
Может в рамках учебной и сделаете нужный пиплу проект.
а то любой тупой 1С-ник спит и видит 1С под линусом.....(это не шутка)....
Ибо так {вырезано самоцензурой} с этим вайном, что, просто,...........

+Кстати, можно ТЗ посмотреть?

defnull, можешь в аську постучаться?

Сообщение отредактировал trdm - 9.3.2009, 23:41

[Litkevich Yuriy]

натрахались

ребята давайте избегать таких слов

[trdm]

так, а в ответ тишина. понял...
ПС, а чего, удалять свои сообщения нельзя?

Сообщение отредактировал trdm - 9.3.2009, 23:52

[ViGOur]

так, а в ответ тишина. понял...

так времени мало прошло и defnull скорее всего не успел прочитать еще.

ПС, а чего, удалять свои сообщения нельзя?

нельзя.

[defnull]

Отчего же нельзя, можно=) правда сомневаюсь что там будет что-нибудь особо интересное.
Сейчас по аське постучаться не могу, если всё же интересно могу залить куда-нить ТЗ-шку?

[trdm]

Отчего же нельзя, можно=) правда сомневаюсь что там будет что-нибудь особо интересное.
Сейчас по аське постучаться не могу, если всё же интересно могу залить куда-нить ТЗ-шку?

mailto:trdmval(все известный зверь)gmail.com
Меня собственно всегда клинило при мысли, что у нас в стране учебные программы
пишутся для чего угодно, только не для практического в последствии применения.
В очередной раз вспоминаю, что разработки американских вузов давно и успешно
применяются на практике (Беркли например). И постоянно вспоминаю 2 российских беды...

Сообщение отредактировал trdm - 10.3.2009, 0:33