Требуется совет по поводу архитектуры.. Опции Подписка на тему Сообщить другу Версия для печати Скачать тему Подписка на этот форум Режимы отображения Переключить на: Древовидный Переключить на: Стандартный Линейный

[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

[defnull]

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

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

Как сказать... мне тема интересна. Меня радует что можно эксперементировать, исследовать, при должном желании можно действительно многому научиться. Вопрос только в том что ТЗ слишком в общих словах, хотя и даёт представление о проекте. К тому же везде есть специфика преподавания.. Вообщем я хз будет интересно или нет вот и решил заранее предупредить.

з.з.ы Отправил)

[trdm]

могу кстати поделиться своими набросками/ТЗ по унстудио
и запустить вашу комманду в репу на гуглях.
ПЫСЫ: вирусов в письме нету?

[defnull]

могу кстати поделиться своими набросками/ТЗ по унстудио
и запустить вашу комманду в репу на гуглях.
ПЫСЫ: вирусов в письме нету?

Кидай, вирусов? Чего не знаю того не знаю, вроде всё чисто))) предохраняйся
ТЗ-шку кидай=) будет интересно глянуть... по поводу гугла ты имел ввиду svn для open sourse проектов который у гугла? если svn то не.. у меня дома поднят + на firstvds сервак где он тоже есть)

[trdm]

хм, т/з на сервисный центр.
я сам работаю в организации где есть сервисный цент по ремонту сотовых и пр. электронной техники...
есть даже некоторые наработки в 1С-ной базе по ремонтам.

ТЗ-шку кидай=) будет интересно глянуть... по поводу гугла ты имел ввиду svn для open sourse проектов который у гугла? если svn то не.. у меня дома поднят + на firstvds сервак где он тоже есть)

да, свн на гугле.
у меня у самого дома поднят, но интернет репа она тоже небесполезна..

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

[defnull]

хм, т/з на сервисный центр.
я сам работаю в организации где есть сервисный цент по ремонту сотовых и пр. электронной техники...
есть даже некоторые наработки в 1С-ной базе по ремонтам.

Там довольно много урезанно, например склада как такового там нет. Всему виной сроки и небольшая команда..=(( Успеть бы хотя бы то что там написанно хех..

[trdm]

а, один черт, для такой системы с 9 пользователями использование С++ нерационально/жирно будет.
не те объемы.
Таким системам за-глаза хватает веб-интерфейса.
И на таких объемах рационально было бы применить 1С-ку или унстудио, если была бы готова.

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

[Litkevich Yuriy]

trdm, ты куда-то к ТЗ ушел от основной темы. Давай-ка поближе.

или унстудио

это только отчетник как я понимаю, а не АРМ (автоматизированное рабочее место) или я неправильно понял?

[defnull]

ты куда-то к ТЗ ушел от основной темы. Давай-ка поближе.

Кстати да=(( вопрос -то ещё открыт... да и средства обсуждать сейчас увы не поможет. С унстудио не знаком..

[trdm]

trdm, ты куда-то к ТЗ ушел от основной темы. Давай-ка поближе.

или унстудио

это только отчетник как я понимаю, а не АРМ (автоматизированное рабочее место) или я неправильно понял?

Основная идея это среда и набор компонент для строительства АРМов. Отчетник это один из компонентов.

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

[Tonal]

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

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

С трёхзвенкой по моему заморачиватся не нужно - только сложность увеличите.

[defnull]

Все данные о пользователях хранятся в отдельной табличке.
Приложение, проверяет по ней доступы и работает или нет дальше.
Если работает, можно периодически проверять не отключили ли тебя.

Да, если сервер поддерживает рассылку нотификаций (Firebird, Postgres), проверку можно инициировать именно ей.

Спасибо вам!!! Про нотификацию не читал.. надо бы посмотреть эти разделы) В какой-то степени роль сервера состояла и в том, чтобы уведомить клиентов, а раз такая задача без проблем решается другими средствами, то поробуем решать именно через них..

Только вот что делать с бекапами??

[Tonal]

У Firebird в составе его API есть работа с бекапом.
В драйвере Qt э того нет, поэтому придётся использовать напрямую или взять либу где оно есть.

По поводу Postgres просто не в курсе.

П.С. Для спасибы тама кнопочка есть.