Работа с БД по сети с разграничением прав.

[JamS007]

Здравствуйте, коллеги.

Опишу сначала ситуацию. Нужно написать кроссплатформенное приложение, работающее с БД, размещенной на удаленном сервере. Работать должны несколько пользователей одновременно, в том числе и с одной БД. Также должно быть реализовано разграничение прав (достаточно запутанное). Признаюсь честно, опыта такой работы - 0. Умею работать с сетью, и частично с БД. Если позволите, несколько вопросов:

1. Стоит ли реализовать промежуточный сервер (проверяющий права и работающий с сервером БД локально) для доступа к БД? То есть, чтобы сначала сервер (написанный мною) проверял права, закреплял соединение, открывал БД и т.д. Но в таком случае я не знаю, как передать управление БД на клиентскую сторону.

2. Использовать готовый сервер БД (говорят они тоже позволяют ставить пароль на БД и ограничивать доступ). Но в таком случае нарушается контроль над приложением, так как настройка сервера будет идти через стороннее ПО.

3. Как вообще лучше реализовать систему, подобную этой?

П.С. Времени - не ограничено, так что лучше сделать медленно, но качественно. Подскажите, пожалуйста, в какую сторону копать?

[eugene]

Лучше 2й вариант, хотя задача не совсем понятна. Сервер можно настроить и через обычное соединение, хотя мб не полностью. Вот тут пример как добавлять юзеров в MySQL: http://www.mysql.ru/docs/man/Adding_users.html

[Urvin]

Все зависит от требований к системе.
Двузвенную систему писать легче и быстрее, но вся бизнес-логика сосредоточена будет в клиентских приложениях, что не всегда есть хорошо.
Трехзвенная система гораздо сложнее, но на нее можно повесть много разных плюшек. Главное преимущество - бизнес-логика едина и сосредоточена в сервере приложений.

Разграничение прав надо производить как средствами СУБД (буквально пароль и ограничение действий над некоторыми таблицами), так и средствами непосредственно приложения.

[asvil]

На мой взгляд промежуточный сервер лишний? Будете ли Вы использовать SQL БД? Если так, то мои рекомендации следующие:
1. Создать некоторый набор групп/пользователей и разграничить их права. Для этого Вам потребуется ну руководоство по администрированию sql серверов.
2. Выделить набор функций предоставляемых пользователю (открыть форму, отредактировать форму, выполнить отчет, просмотреть таблицу/представление и т.д.)
3. Назначить каждой функции из набора уникальный идентификатор. Я использовал для этого строковый тип.
4. Создать две таблицы в базе данных следующих структур:

Код:

user
(
user_id integer pkey
name text
-- other attributes
)

user_right
(
id integer pkey
user_id integer fkey(user, user_id)
object_id text
rights unsigned integer
)

5. Предоставить пользвателю ввести логин, пароль. Подключиться к БД под введенным аккаунтом.
6. Выполнить "select object_id, rights from user_right join user on (user_id) and user.name = current_user()". Вместо current_user может быть несколько другое имя функции.
7. Сделать QHash<QString, uint> rights, заполнить его

Код:

QHash<QString, uint> rights;
while(query.next())
  rights.insert(query.value(0), query.value(1));

8. Теперь проинициализировать список доступных пользователю функций можно так:

Код:

foreach (stringObjectName, Objects) {
  if (rights.value(stringObjectName) & RIGHT_WRITE) {
     addToWriteUI();
  } else if (rights.value(stringObjectName) & RIGHT_READ) {
     addToReadUI();
  } else if (rights.value(stringObjectName) & RIGHT_EXECUTE) {
     addToExecuteUI();
  }
}

Как сделать формочку администрирования прав, да и вообще как организовать код отвечающий за графические объекты доступа к БД я не рассказал.
Но важно понять что разграничивать доступ необходимо в двух местах. В базе данных и в приложении.
Логику процесса предментной области рекомендую реализовывать в БД в виде хранимых процедур, триггеров. Ну и начать стоит именно с программирования на sql.
P.S. Почему нарушиться контроль над приложением, если настройка сервера будет осуществляться через стороннее ПО? Вы будете настраивать SQL сервер через стороннее ПО по определению. Ваше приложение должно общаться только с таблицами и представлениями и recordset'ами возвращаемыми от select, insert...returning, update...returning. Хотя я немного вру. Для реализации системы прав доступа понадобиться еще команды семейства (create/alter user).

[crossly]

+1

Двузвенную систему писать легче и быстрее, но вся бизнес-логика сосредоточена будет в клиентских приложениях, что не всегда есть хорошо.
Трехзвенная система гораздо сложнее, но на нее можно повесть много разных плюшек. Главное преимущество - бизнес-логика едина и сосредоточена в сервере приложений.

не лучший подход.... бизнес логику желательно реализовать на сервере.... с помощью средств предоставляемых сервером ( процедуры, триггеры и т.д.)

[JamS007]

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

Опишу свое видение решение: в комплект с северной частью моей программы впихнуть какой-нибудь сервер БД. (Скорее всего - PostgreSQL) Устанавливать его походу установки моего приложения.

Мой сервер будет общаться с моими клиентами, проверять их права, и т.д. и вносить изменения непосредственно в БД, а клиентам будет отправлять данные совсем в другом формате, но при таком раскладе - еще и синхронизация падает на меня одного.

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

[asvil]

Скрипт автоматизации развертывания и настройки - самый правильный вариант.
А Вы смел. В качестве примера советую посмотреть на реализацию erp что-ли системы - tryton.
А интересно Ваша аудитория сможет разобраться, что такое серверная часть и клиентская? И как их вместе соединить? И что сделать, если "кнопочки не работают"?

[JamS007]

Дело еще в том, что сервер уже почти написан, но он не использует никакой БД вообще, он сам себе режиссер. Все прекрасно работает, но появилась нужда выводить еще информацию на сайт, и веб-программист хочет работать с БД. Информацию дублировать смысла нет, поэтому принято решение пока не поздно перевести сервер на какую нибудь базу данных. Возлагал надежды, что это только упростит мне работу, но вижу что не тут то было

Вот почитал еще на одном сайте, что 3х звенчатая система хороша тем, что позволяет производить дополнительную верификацию данных, в какой то степени уберегает от sql инъекций, позволяет контролировать версии клиентов, предоставлять обновления ну и т.д. Верно ли это?

[asvil]

Ну да, расскажите тогда о сервере и о клиентах. Может Вам sql не нужен? Проведем сравнение функционала Вашего сервера и sql.

[JamS007]

Рассказываю:

Сервер многопоточный (используется пул потоков, и оптимизация выполнения запросов пользователей), макс кол. потоков  = кол. ядер в системе - 1 или 1 для одно ядерных машин (хотя их я не рассматриваю как претендентов на сервер). Вся информация пишется на диски силами файловой системы, продуман некоторый механизм оптимизации, но если честно -  доверия он мне не внушает. Тест еще не проводили, но по расчетам должно работать хорошо.  Размер такой БД для (частного случая) в моей скромной реализации - 256кб-1мб (на одного клиента). Такой маленький размер достигается перезаписью файла с информацией полностью при поступлении новых данных. Таким образом никакого резервирования места на диске для данных, как это делается в СУБД, не происходит. Согласен - для больших файлов - это не годиться, но в данном случае - вполне подходит.

В PostgreSQL я ожидаю намного большего размера данных, но вместе с этим и некоторого порядка в структуре, и уменьшении кода.

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

Добавлю только что клиентов много, от 50 до 200-300. Частота изменений данных приблизительно 0.5 - 1 сек. Объем изменяемых данных от одного клиента ~ 10-50кб / запрос. Ну и при перезаписи файла данных происходит торможение (переписываться с интервалом в 1-1,5 часа)

Ну и сервер должен быть кроссплатформенным, а играться с скриптами для каждой платформы желания нет.

[asvil]

Ну тогда всего лишь замените метод хранения данных, перенеся ответственность на SQL СУБД.