crossplatform.ru

Здравствуйте, гость ( Вход | Регистрация )

defnull
  опции профиля:
сообщение 9.3.2009, 20:38
Сообщение #1


Студент
*

Группа: Участник
Сообщений: 49
Регистрация: 1.5.2008
Пользователь №: 165

Спасибо сказали: 0 раз(а)




Репутация:   1  


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

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

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

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

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

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

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

Был бы очень признателен если бы кто-нибудь дал развёрнутый ответ что в данном случае предпочтительнее использовать..
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
 
Начать новую тему
Ответов
Tonal
  опции профиля:
сообщение 13.3.2009, 21:56
Сообщение #2


Активный участник
***

Группа: Участник
Сообщений: 452
Регистрация: 6.12.2007
Из: Новосибирск
Пользователь №: 34

Спасибо сказали: 69 раз(а)




Репутация:   17  


Если на работу с пользователями и секретностью не накладывается дополнительных ограничений, то вполне подходит такая схема:
Все данные о пользователях хранятся в отдельной табличке.
Приложение, проверяет по ней доступы и работает или нет дальше.
Если работает, можно периодически проверять не отключили ли тебя. :)
Да, если сервер поддерживает рассылку нотификаций (Firebird, Postgres), проверку можно инициировать именно ей.

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

С трёхзвенкой по моему заморачиватся не нужно - только сложность увеличите.
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение

Сообщений в этой теме
- defnull   Требуется совет по поводу архитектуры..   9.3.2009, 20:38
- - ViGOur   ИМХО, лучше использовать 2 вариант. Минусы этого в...   9.3.2009, 22:02
- - trdm   Цитата(defnull @ 9.3.2009, 20:38) Был бы ...   9.3.2009, 22:45
|- - defnull   Система является учебным а не реальным проектом. В...   9.3.2009, 23:11
- - trdm   Делайте толстого клиента, а сорцы публикуйте на гу...   9.3.2009, 23:38
- - Litkevich Yuriy   Цитата(trdm @ 10.3.2009, 2:37) натрахалис...   9.3.2009, 23:40
- - trdm   так, а в ответ тишина. понял... ПС, а чего, удалят...   9.3.2009, 23:48
- - ViGOur   Цитата(trdm @ 9.3.2009, 23:48) так, а в о...   10.3.2009, 0:10
|- - defnull   Отчего же нельзя, можно=) правда сомневаюсь что та...   10.3.2009, 0:24
|- - trdm   Цитата(defnull @ 10.3.2009, 0:24) Отчего ...   10.3.2009, 0:30
|- - defnull   Цитата(trdm @ 10.3.2009, 0:30) Цитата(def...   10.3.2009, 0:35
- - trdm   могу кстати поделиться своими набросками/ТЗ по унс...   10.3.2009, 0:39
|- - defnull   Цитата(trdm @ 10.3.2009, 0:39) могу кстат...   10.3.2009, 0:43
- - trdm   хм, т/з на сервисный центр. я сам работаю в органи...   10.3.2009, 0:43
|- - defnull   Цитата(trdm @ 10.3.2009, 0:43) хм, т/з на...   10.3.2009, 0:45
- - trdm   а, один черт, для такой системы с 9 пользователями...   10.3.2009, 0:52
- - Litkevich Yuriy   trdm, ты куда-то к ТЗ ушел от основной темы. Давай...   10.3.2009, 1:12
|- - defnull   Цитата(Litkevich Yuriy @ 10.3.2009, 1:12)...   10.3.2009, 1:16
|- - trdm   Цитата(Litkevich Yuriy @ 10.3.2009, 1:12)...   10.3.2009, 18:36
- - Tonal   Если на работу с пользователями и секретностью не ...   13.3.2009, 21:56
|- - defnull   Цитата(Tonal @ 13.3.2009, 21:56) Все данн...   14.3.2009, 13:35
- - Tonal   У Firebird в составе его API есть работа с бекапом...   14.3.2009, 16:59


Быстрый ответОтветить в данную темуНачать новую тему
Теги
Нет тегов для показа


1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0


RSS Рейтинг@Mail.ru Текстовая версия Сейчас: 18.7.2025, 12:20