![]() |
Здравствуйте, гость ( Вход | Регистрация )
![]() |
defnull |
![]()
Сообщение
#1
|
Студент ![]() Группа: Участник Сообщений: 49 Регистрация: 1.5.2008 Пользователь №: 165 Спасибо сказали: 0 раз(а) Репутация: ![]() ![]() ![]() |
Добрый день. Хотел бы посоветоваться по поводу архитектуры разрабатываемой системы.
Задача: есть сервер на котором крутиться PostgresSQL. Есть АРМ разных видов которые должны иметь доступ к данным бд на сервере и которые должны работать с базой параллельно. База данных должна бекапиться удалённо, и удалённо же должно производиться управление учётками пользователей. Проект выполняется с использованием QT на С++. Подключение к БД через qt модуль работы с postgresql. Возникшие проблемы: 1) не до конца ясно делать ли серверную часть и насколько должны быть толстыми или тонкими клиенты. 2) не понятно какими средствами лучше всего бекапить удалённо базу и как управлять учётками. Выявил несколько вариантов: 1) Без серверной части. То есть админ ставит БД, подключается к ней со своего (АРМ), заводит пользователей и те напрямую работают с базой. Из плюсов - вроде бы простота реализации. Из минусов - сложности контроля пользователей и проблемы с их блокировкой (например надо отслеживать работает ли пользователи в текущий момент с базой чтобы сделанный бекап не был противоречивым) Нельзя проконтролировать пользовательскую активность напрямую с админского АРМ (здесь и далее админская часть на его собственном компе а не на сервере) 2) Серверная часть как прокси. Тоесть клиент вначале подключается к серверной части а та пускает или не пускает его на работу с базой. Из плюсов: учёт активности пользователей. Возможность заблокировать пользователя почти в любой момент. Из минусов: Дополнительный расходы на сервер(по два соединения tcp вместо одного когда нет серверной части). Не ясно можно ли просто перенаправлять всю инфу с одного сокета в другой после того как мы пускаем пользователя??? (идея такая.. клиент авторизуется на сервере и тот далее подключается к бд под учётной записью пользователя и передаёт информацию от клиента к бд и от бд клиенту через себя) 3) Клиент проходит авторизацию на сервере а после если авторизация успешна напрямую подключается к БД. При этом от клиента идёт два соединения к Серверу и к БД. Сервер управлять клиентом (например послать запрос чтобы клиент разорвал связь с БД) Из плюсов: учёт активности пользователей. Возможность заблокировать пользователя почти в любой момент. Из минусов: Дополнительный расходы на клиента(по два соединения tcp вместо одного когда нет серверной части). Да и в целом схема мне кажеться несколько усложнённой.. А уж с бекапом вообще не ясно как быть. Условия таковы что нельзя использовать сторонние утилиты по резервированию/восстановлению, тоесть даже pgdump использовать по идее нельзя. А если всё же использовать, то надо писать обёртку... Но pgdump вроде бы здесь не подойдёт он ведь должен работать на той же машине где и БД. Был бы очень признателен если бы кто-нибудь дал развёрнутый ответ что в данном случае предпочтительнее использовать.. |
|
|
![]() |
Tonal |
![]()
Сообщение
#2
|
![]() Активный участник ![]() ![]() ![]() Группа: Участник Сообщений: 452 Регистрация: 6.12.2007 Из: Новосибирск Пользователь №: 34 Спасибо сказали: 69 раз(а) Репутация: ![]() ![]() ![]() |
Если на работу с пользователями и секретностью не накладывается дополнительных ограничений, то вполне подходит такая схема:
Все данные о пользователях хранятся в отдельной табличке. Приложение, проверяет по ней доступы и работает или нет дальше. Если работает, можно периодически проверять не отключили ли тебя. ![]() Да, если сервер поддерживает рассылку нотификаций (Firebird, Postgres), проверку можно инициировать именно ей. Можно несколько усложнить схему, использовать доп.подключение, процедуры, роли. Так чтоб довольно сильно осложнить взлом этого дела со стороны, ежели критично. Но для учебной задачи вроде и так покатит. ![]() С трёхзвенкой по моему заморачиватся не нужно - только сложность увеличите. |
|
|
![]() ![]() ![]() |
![]() |
|
Текстовая версия | Сейчас: 18.7.2025, 12:20 |