Создание и организация блока администрирования баз данных IBase

← →
GaM (2003-10-29 18:43) [0]

Привет мастера, у меня вот будет такой вопрос к вам (заранее пошу прощения)если некоторые мои вопросы покажутся глуповатыми или даже дурацкими.
Здесь на форуме уделено много внимания и вопросам использования скажем триггеров,ХП, созданию структур БД, корректной и грамотной работе при создании запросов к БД, но вот функциям и способам грамотного администрирования БД как мне кажется почти не уделяется внимания.
Так вот перейдем к вопросам:
При создании, удалении и модификации пользователей я использую компонент IBSecurityService (кстати в папке Demos есть не плохой пример по обслуживанию БД IB, это для тех, кроме конечно вас мастера, кто как и я считает себя новичком или если кому-нибудь угодно Чайником в вопросах проектирования БД, ток кто уже к примеру задавал в форумах вопрос,который как то задавал и я "Как из программы осуществить добавление пользователя в БД" и получал на это какие-то невразумительные ответы и интересно что никто из ответивших даже не посоветовал
заглянуть в папку \Demos\DB ну я понимаю крутые перцы, что им примеры Borlanda),заношу данные о пользователях в isc4 ну или
admin (в случае IBase 7xx). Но вот данных о пользователе в этой таблице мне в данный момент недостаточно, хотелось бы иметь данные скажем о времени последнего подключения пользователя к базе, разбить пользователей на операторов, помошников администратора ну и соответственно главный админ (все я повторяю в данном случае условно можно много еще чегу придумать в зависимости от поставленной задачи),раздавать привилегии пользователям. Допустим помошнику администратора дать право на добавление пользователя, дать право оператору на выбор различных
ролей при подключении к базе и т.д. Я вот думаю правильно ли будет вот такой вариант:
в своей БД создаю таблицу которая бы дублировала isc4 плюс добавление своих полей дата последнего подключения права на доступ, различные параметры вроде того в каком отделе числиться пользователь и т.д.
Может кто-то из вас занимался подобными вопросами, если не сложно дайте совета, может ссылку на пример, а лучше бы взялся бы кто-нибудь из мастеров за написание большой и грамотной статьи
на подобную тему, снабженную кусками кода с комментарием почему сделано так а не иначе.
Я думаю мой первый вопрос понятен, я упустил некоторые моменты которые считаю итак домыслять люди занимающиеся проектированием приложений баз данных и в частности удиляющие большое
внимание вопросу данной темы.

P.S. у меня к вам большая просьба таких новичков как я очень много если можно при ответе на поставленный мною вопрос не отвечать фразами типа накатай генератор который будет...а там сам
типа домыслишь, сляпай ХП которая...ну ты меня понял, которая...
А ответить постараться грамотно, действительно статься бы не помешала, может кто и возьмется а?
И может кто подскажет лит.источник для новичка, выбор книг большой но вот кто пишет конкретнее,
понятнее и грамотнее не всегда понятно.
Всем пока. Удачи!!!

← →
Zacho (2003-10-30 07:43) [1]

> GaM (29.10.03 18:43)
> Я вот думаю правильно
> ли будет вот такой вариант:
> в своей БД создаю таблицу которая бы дублировала isc4 плюс
> добавление своих полей дата последнего подключения права
> на доступ, различные параметры вроде того в каком отделе
> числиться пользователь и т.д.

Правильно. Вполне нормальный и часто используемый подход.
Даже можно пойти дальше. Часто требуется разграничить права пользователей не на уровне таблиц, а на уровне отдельных записей. Решается это, например, так: кроме таблицы пользователей создаются таблицы прав пользователей для каждого объекта, требующего разграничения прав доступа (например склады, поставщики и т.п). Доступ к "защищаемым" таблицам закрывается всем юзерам (кроме SYSDBA, естественно :) ) и работа с ними идет только с помощью VIEW и/или хранимых процедур, в которых уже учитываются права пользователя из соответствующей таблицы прав.
Вот пример (крайне упрощенный)

Таблица складов STORES
ID INTEGER - первичный ключ
------------------

Таблица пользователей USERS
USER_NAME VARCHAR -первичный ключ
------------------
Таблица прав пользователей на склады USERS_STORES
USER_NAME - внешний ключ на таблицу USERS
ID_STORE - внешний ключ на таблицу STORES
Первичный ключ по полям USER_NAME,ID_STORE
------------------
Для упрощения будем считать, что есть только два типа доступа: склад доступен для юзера (и тогда в таблице USERS_STORES есть запись с именем пользователя и ID склада) и склад не доступен для юзера (тогда такой записи нет)
Для работы пользователей с таблицей STORES создадим VIEW c триггерами или SP с запросом такого вида:
SELECT * FROM STORES S
JOIN USERS_STORES US
ON S.ID=US.ID_STORE AND US.USER_NAME=CURRENT_USER
Дадим этой ХП (или VIEW) все права на таблицу STORES, пользователям - права на запуск SP (или на чтение/модификацию VIEW), на саму таблицу STORES пользователям права давать не будем.
Для упрошения администрирования еще можно ввести понятие "группа пользователей" (администраторы, операторы и т.п.) и соответствующие таблицы с правами групп. (что-то типа интербейзовских ролей)

← →
Sergey13 (2003-10-30 08:37) [2]

2GaM (29.10.03 18:43)
ИМХО, у тебя есть желание на бесплатном серваке иметь все удовольствия коммерческого продукта. ИБ всегда славилась именно тем, что ей не нужны администраторы. Но, как ты сам видишь, это не всегда плюс.

ЗЫ: Вообще тема больше в потрепаться подходит, ИМХО

← →
Alexandr (2003-10-30 08:41) [3]

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

Создание и организация блока администрирования баз данных IBase Найти похожие ветки