Администрирование

← →
Начинающий10 (2006-02-28 09:44) [0]

Господа программисты и им сочувствующие, поделитесь соображениями или опытом.
Собственно преамбула. Сделал не так давно программный комплекс на базе СУБД MSSQL который помимо прочего обеспечивал занесение, хранение и т.д. ретроспективной информации в следующих таблицах:
родительская, заточенная под DBTreeView, является в моем случаи хранилищем элементов оборудования;
дочерние таблицы (бланки), содержат, соответственно, описания элементов оборудования.
Ну и табличка с пользователями для примитивного администрирования на уровне бланка в целом (видимость, редактирование).
В общем типовая задачка :)
Все чудненько работает, но в последние время все настойчивее склоняют к более «глубокому» администрированию, а именно - редактирование, видимость и т.д. вплоть до записи в бланке и столбца бланка.
Реализовал желание созданием дополнительного поля в родительской таблице в которое записывается объектик. Объектик, на каждую запись соответственно, содержит всю информацию о бланках > записях об элементе > столбцах > конкретном пользователе, и реализован на основе вложенных TCollection. Короче жуткий монстр и жрет достаточно много.
Собственно не нравиться мне ента реализация, а другой придумать не могу :(. Поделитесь соображениями или опытом, возможно есть более простые и элегантные способы достигнуть результата (без использования средств СУБД). Спасибо.

← →
MOA © (2006-02-28 09:50) [1]

1. Нормализовать Вашу базу минимум до 3-й усиленной нормальной формы.
Как только это будет сделано - Вы сможете воспользоваться механизмами безопасности MSSQL - ролями, правами на объекты.
Удачи!

← →
Начинающий10 (2006-02-28 10:05) [2]

Собственно пожеланием было редактирование прав из дополнительной «программки» комплекса, то есть их администратор ничего не должен знать и не уметь пользоваться утилитами СУБД. Хотя я может что-то не понимаю, так как сам недавно переработал комплекс с Paradox на MSSQL без использования всяких прибомбасов.

← →
clickmaker © (2006-02-28 10:16) [3]

создать что-то типа ACL
ACL_ID User_ID Object_ID Rigths
где Object_ID либо таблица, либо запись, либо столбец
Rights - набор флагов (н-р, 1 - читать, 2 - писать, 4 - удалять, 0 или отсутствие записи - нет доступа)
в качестве Object_ID могут выступать и id из sysobjects и syscolumns для упрощения. Редактируется этот acl с самописного клиента, юзер в сиквельную секьюрити не лезет

← →
MOA © (2006-02-28 10:22) [4]

>администратор ничего не должен знать и не уметь пользоваться утилитами СУБД
Для управления системой безопсности в MSSQL используются команды и процедуры самого MSSQL (не утилиты), т.е. админ может и не уметь, если написать для него соответствующую оболочку этих команд ;)
Посмотрите в BOL про GRANT, REVOKE, sp_addrole и по ссылкам с них.
Требование 3-й усиленной формы обусловлено тем, что в этом случае права можно назначить более детально - конечно, механизмы безопасности сервера работают безотносительно к уровню нормализации.
Удачи!

← →
Начинающий10 (2006-02-28 10:49) [5]

>[4] Оставлю на сладкое :)
>[3] Гениально. В смысле раньше не приходило в голову уникально обзывать записи и столбцы вне таблиц. Правда размерчек у этой таблицы будет :)
Спасибочки.

> редактирование, видимость и т.д. вплоть до записи в бланке и столбца бланка.
Это как? половину бланка видно, половину - нет???
Может, не "склоняться", а за отдельные деньги продумать политику администрирования?

Администрирование Найти похожие ветки