Реализация системы доступа и АРМа Администратора доступа.

← →
_Lucky_ (2005-12-07 13:51) [0]

Как в коммерческих системах реализована система доступа, и АРМ Администратора доступа
т.е. на вид это выглядит так:
Администратор доступа запускает АРМ доступа в котором заводит нового пользователя,
дает ему опеределенные права на выполнение операций и т.д. При этом он не пишет SQL команды, а тыкает мышей, отсюда вытекает вопрос реализации этого механизма. Т.е. заводят ли они какие-то специальные таблицы или как?

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

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

В принцепе все это интересует приминительно к FireBird 1.5, но если есть какие-то базовые методы, то тоже было бы не плохо их узнать. А м.б. FireBird на такое не способен и нужно просто переходить на что-то более мошьное, я лично видел примеры таких систем на MS SQL и Oracle.

Может есть статейки по этому поводу?

← →
Sergey13 © (2005-12-07 13:58) [1]

Наверное все (почти) зависит от того как реализована собственно система доступа. То ли это возложено на сервер БД, то ли реализоано в своих таблицах и вшито в приложение, то-ли некая комбинация первого и второго.

Поищи в инете (или еще где) про роли (как совокупность прав пользователя) в БД.

← →
alex_*** © (2005-12-07 14:10) [2]

то ли на безопастость винды

← →
_Lucky_ (2005-12-10 16:48) [3]

Однако жаль, что никто дельного совета не дал.
Про роли читал, тоже впечатлений 0, потому что там одни SQL команды, я допустим с ними разберусь, хотя это вопрос уже другой, ну а по завершении проекта мне прийдется написать администратору шпору с SQLем, типа напишешь эту команду и пользователь сможет выполнять такие операции, напишешь вот эту и у него появится вот такая операция - в коммерческих прогах которые я видел, у админа был АРМ которым к серверу цеплялся и видел всех пользователей, их права, также там были группы которые содержали операции, он мог их изменять, создавать новые, удалять.
Причем все было понятно, потому что SQL писать не приходилось, он просто кликал на нужных описаниях (типа "Проводка материальных счетов") и все.
В этом же арме он мог видеть/настраивать когда пользователю менять пароль, какой сложности должен быть пароль, какой мин длины, блокировать пользователя, разблокировать, ставить количество ошибок в вводе пароля и т.д.
А я вот чего-то не могу понять как мне это сделать с тем же FireBird, ну вот есть у меня база, сделал я пользователей, но у них нет описанных выше свойств, думал может добавить в базу таблицу с пользователями и их не достоющими свойствами, но тогда прийдется заводить их 2 раза, такое же решение и относительно прав пользовалей создать таблицу в котору внести все операции и таблицу груп, но вот терзают смутные сомнения относительно того, а нет ли способов проще?

← →
sniknik © (2005-12-10 18:23) [4]

> мне прийдется написать администратору шпору с SQLем, типа напишешь эту команду и пользователь сможет выполнять
> такие операции...

не придется, если ты эти sql команды "подвесиш" на кнопочки, либо на > "нужных описаниях (типа "Проводка материальных счетов")"

> ну вот есть у меня база, сделал я пользователей...
не пользователей, а пользователя - одного, админа системы, у которого дожна быть реализована возможность самому создавать/настраивать пользователей/права. (один типа системного должен создаваться с базой, и удалятся не должен (возможности чтобы не было))

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

кстати, действительно, не путай права на базу и права юзера в самой программе, в том же самом рассматриваемом АРМ. (вполне возможно там самый "бесправный" юзер работает под учетной записью админа базы... ну просто не может по другому, сделали так, что все под одним. ;))
(у меня кстати в этой проге тоже все под "овнером" базы "ходят" и ничего. и в 1С также сделано (7ке, 8 не знаю), а в программе уже делится)
то что про sql читал это на права на базу, то что таблицами пытаешся реализовать это получается права в программе, "програмным" пользователям .

вот эти "твои таблицы" я сделал просто набором (set of byte) и храню их в блоб поле записи, но не у юзера а у юзерового типа (их три см. up), в общем то все, при логине набор считывается и по проверке tag in set закрываются/открываются пункты меню (tag-и у них заранее прописал), вот и все разделение прав. ;)
и редактировать можно, в проге не реализовано, но если меняются их "жосткие" требования к правам, поменять их мне пара пустяков. (надо сказать менял всего раз. удивлен ;)
"на крайняк" можно и на каждого юзера такое поле завести, добавить только механизм редактирования этого поля, с подписями что какой бит значит, и будут настраиваемые поля для каждого юзера.

← →
_Lucky_ (2005-12-11 13:35) [5]

А по поводу политики безопасности юзеров? ну т.е. срок жизни паролей, блокирование пользователей, разблокирование, не повторяемость паролей, сложность паролей и т.д.

Кстати у меня система как раз банковская, хотя и не хранящая финансовой информации, но всеже у них есть четкие и жесткие требования к обеспечению безопасности автоматизированных систем.

> не придется, если ты эти sql команды "подвесиш" на кнопочки,
> либо на > "нужных описаниях (типа "Проводка материальных
> счетов")"

Ну это совсем не интересно, потому что допустим у меня порядка 50 операций, делать 50 кнопочек - это не совсем красиво, да и если нужно будет сделать какие-то изменения, то тоже получится напряжно.
Я думал сделать таблицу в которой скажем написать (наименование операции, SQL ит.д.) ну и типа туда забить все операции, просто тут же встала мысль о том, что м.б. где-то в оракле или мс сиквеле это реализованно на уровне самой субд.

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

← →
Sergey13 © (2005-12-12 09:26) [6]

2 [5] _Lucky_ (11.12.05 13:35)
> Ну это совсем не интересно, потому что допустим у меня порядка 50 операций, делать 50 кнопочек - это не совсем красиво, да и если нужно будет сделать какие-то изменения, то тоже получится напряжно.

Интересно, а в юзерской программе (не админовской), у тебя 1~2 функции и ты обходишься без SQL?
ИМХО вам надо программиста приглашать для этой работы.

← →
_Lucky_ (2005-12-12 13:36) [7]

> Sergey13 © (12.12.05 09:26) [6]

Ну собсна я и есть программист =)
Хотя работаю не программистом, и приглашать его туда никто не будет, это ваще самодеятельность, так сказать перед начальством вы...ся - глядишь чего и получитсо.

По поводу SQL и кнопочек - в юзерской программе тоже достаточно функций, но ведь подумай сам в админской проге предпологается наличие таких функций как добавление нового пользователя, предоставление/изъятие прав, блокирование/разблокирование, сброс пароля, по идее все, ну м.б. чего забыл, не в этом суть, так вот предоставление прав мне что прийдется менять (или писать новую) каждый раз как появится новая функция? фигня.
ведь я не думаю что кто-то, пуская в юзерской программе, делает отчет например условно для счета 42301, а потом когда в балансе появляется счет 70107, то еще дописывает отчет для этого счета, хотя отчеты на самом деле одинаковые, и так каждый раз при появлении нового счете, наверняка делается одна функция отчета, у которой есть параметр номер счета - допустим, который в свою очередь хранится в одной из таблиц, так зачем же я буду делать 50 кнопочек и каждый раз лезть в исходники и делать новую кнопочку, когда можно взять написать функцию предоставления прав, а при появлении новых полномочий включать их в список (добавлять в таблицу).

← →
Sergey13 © (2005-12-12 13:46) [8]

2 [7] _Lucky_ (12.12.05 13:36)
Я что-то понимаю все меньше и меньше в твоем вопросе. 8-)
Кто писал прогу для юзеров (не админскую)? Как там реализованы эти самые права доступа которые надо администрировать? О какой вообще БД идет конкретно речь?

← →
sniknik © (2005-12-12 14:00) [9]

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

> Ну собсна я и есть программист =)
извини но не похоже. мышление не то, елементарные вещи воспринимаеш как, как... как менеджер (или даже хуже - бухгалтер!). ;о)

← →
evvcom © (2005-12-12 14:41) [10]

> мысль о том, что м.б. где-то в оракле или мс сиквеле это
> реализованно на уровне самой субд.

Действительно реализовано путем выполнения sql "create user ...", "create role ...", "grant ..." и т.п.

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

Вот именно! Напиши функцию, может даже не одну :)
А еще поищи/почитай про динамический sql

← →
iva © (2005-12-12 15:01) [11]

На http://www.delphiplus.org/ есть статья "Управление пользователями в ПО на основе СУБД Interbase"

← →
ANB © (2005-12-12 17:41) [12]

> _Lucky_ (07.12.05 13:51)

По человечески надо комбинировать и таблицы и штатные средства. Правда, можно использовать сервер приложений и штатные средства могут оказаться уже не нужны. Прежде чем писать АРМ админа, нужно написать саму систему. А уже от ее технологии плясать.
ЗЫ. Частенько не пишут отдельный АРМ админа, а встраивают этот функционал прямо в приложение.
ЗЫЫ. Писать ты это все задерешься, так как SQL, видимо, знаешь плохо.

← →
_Lucky_ (2005-12-13 15:47) [13]

> Я что-то понимаю все меньше и меньше в твоем вопросе. 8-
> )
> Кто писал прогу для юзеров (не админскую)? Как там реализованы
> эти самые права доступа которые надо администрировать? О
> какой вообще БД идет конкретно речь?

Очень жаль, что не понятно.
Прогу никто еще не писал, просто все написанные мною до этого программы, не требовали никакого разграничения, но вот щас мне это стало необходимо, в нескольких коммерческих программах я увидел это и мне стало интересно как у них это реализованно.
СУБД любая, т.е. реально я писал на IB/FB, но если например на FB такое реализовать не возможно или скажем на MS SQL это делается штатными средствами, то значит будуучить новую для меня СУБД.

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

Ну видимо так и есть, только вот чего Вы мне предлагали:

> не придется, если ты эти sql команды "подвесиш" на кнопочки,
> либо на > "нужных описаниях (типа "Проводка материальных
> счетов")"

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

> извини но не похоже. мышление не то, елементарные вещи воспринимаеш
> как, как... как менеджер (или даже хуже - бухгалтер!). ;
> о)

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

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

> Вот именно! Напиши функцию, может даже не одну :)
> А еще поищи/почитай про динамический sql

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

Я лично хочу чтобы было нечно вроде
ДатьПраваПользователю (Юзерь, ИД_Райтз)
и все

> По человечески надо комбинировать и таблицы и штатные средства.
> Правда, можно использовать сервер приложений и штатные
> средства могут оказаться уже не нужны. Прежде чем писать
> АРМ админа, нужно написать саму систему. А уже от ее технологии
> плясать.
> ЗЫ. Частенько не пишут отдельный АРМ админа, а встраивают
> этот функционал прямо в приложение.
> ЗЫЫ. Писать ты это все задерешься, так как SQL, видимо,
> знаешь плохо.

Вот то-то и оно, что хочется узнать как это по человечески, я же не могу знать о бо всем, поэтому и спросил тут. Т.е. например ну не работал я с MS SQL - а м.б. он все это умеет делать штатными средствами, а я буду изобретать велосипед. С другой стороны для решения задача мне хватит и FB, поэтому не вижу причин переходить на что-то другое, тем более, если другая СУБД не решает моей проблемы.
К сожалению точно не знаю чего писать с начала. Но я лично решил написать сначала админа, потому что задача не сложная, в том что с ней справлюсь уверен, а вот админа никогда не делал. При этом не вижу проблем с технологией, тем более что она как-то мне может все испорить (могу сильно ошибатся =)).
Я в курсе что арм админа встраивают прямо в приложение, но из соображений безопасности у нас все разделено.
SQL знаю не так хорошо как хотелось бы, но мне хватает =)

ЗюЫю спасибо за статью.

← →
sniknik © (2005-12-13 16:12) [14]

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

> Я лично хочу чтобы было нечно вроде
> ДатьПраваПользователю (Юзерь, ИД_Райтз)
> и все
примерно то самое у меня и есть ([4] последний абзац) только названо по другому, у меня даются права типу (админ, менеджер, пользователь) а юзеру задается уже этот тип и соответственно его права.
назови это по другому, не тип юзера, а группа предустановленных прав юзера, и не храни в одном месте как у меня (т.к. у меня жесто задано) а копируй в запись юзера (или храни у юзера ссылки на эти группы прав), и будет практически то что ты хочеш.

← →
evvcom © (2005-12-13 16:23) [15]

> отсюда можно сделать один вывод если у меня будет 50 операций,
> то мне понадобится 50 кнопочек, если порядка 500 как в
> той БД которую я видел, значит нужно 500 =)

Неправильный вывод. Завести 10 пользователей - это одна или 10 операций? Операций-то 10, но они однотипные и здесь достаточно одной кнопки. Ввести роль - еще кнопка. Дать полномочия на роль пользователю - еще одна кнопка. И дать полномочия роли или пользователю на выполнение хранимой процедуры, просмотр вьюхи и т.п. еще одна кнопка. Итого 4 кнопки! Реально, конечно, потребуется еще чего-нибудь, но я не думаю, что ты выйдешь за границы полутора-двух десятков кнопок, но это же не 500! И никаких переделок админмодуля.
Естественно в качестве кнопок может выступать кто угодно (кнопки, таблицы, списки и пр.)

← →
evvcom © (2005-12-13 16:26) [16]

> назови это по другому, не тип юзера, а группа предустановленных
> прав юзера

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

← →
Sergey13 © (2005-12-13 16:35) [17]

2[13] _Lucky_ (13.12.05 15:47)
Тебе надо таки определиться - как ты хочешь сделать.

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

2. Дать права на объекты БД ролям (однотипным группам юзеров). Тогда человек сможет читать (например) таблицу счетов независимо от того в какой функции системы он это делает. Или не сможет писать туда, независимо от того, что ему доступен пункт меню "Перелопатить план счетов". БД ему этого не даст.

Можно сочетать эти 2 варианта по разному.

Как только определишься что тебе надо, так будет понятнее (надеюсь) как это сделать.

Учитывая заявленый зоопарк (IB6.x, MSSQL, MySQL, dBase, FoxPro, Paradox), про штатные средства, да и вообще можно забыть.
Надо снизить аппетиты и определиться с минимумом.
Последнии тру СУБД практически беззащитны.

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

> складываешь в зашифрованном виде в БД

а шифровать-то зачем?

чтоб особо продвинутые юзвери ручками (сторонними средствами) не лезли, особенно актуально для тех 3 СУБД, что АП упомянул

А ну если только для тех 3-х... А для остальных это лишнее, так как можно ограничить права пользователей с шаловливыми ручками штатными средствами.

← →
_Lucky_ (2005-12-14 19:38) [23]

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

Вот наконец-то растолковывают =)

Дело то в чем, я например бывший студент, отучился, дипломчик защитил, тока в универе почему-то все не дочитывали, ну и типа базы они прочли, курсач мы сделали, к диплому допустили, мы его сделали, только все базы которые я писал себе и др. людям сдающим дипломы не требовали чтобы там были какие либо ограничения (преподы и так понимали - они хоть что нить сдали бы =)), а даже если у кого из моих знакомых и требовались, то на это всегда был один ответ: "ну это типа учебная разработка, времени мало, но вот когда я буду писать настоящую ..."
А поскольку в моем скромном городишке программеры/разработчики не требуются, то я пошел где было место, а именно в банк аудитором, благо в дипломе написано квалификация экономист (ну государство умеет издеватся таким способом), ну и соответственно никакими разработками на работе не занимался около 2-х лет, все писалось и пишется дома в свободное от работы время - типа хоби. И все написанное для работы используется в тихоря, потому как запрещено это все.
Но вот на работе есть направление которое так и напрашивает на разработку и уж коли братся за него, то сделать все нормально, глядишь начальство и оценит, а раз делать нормально то нужно вот это самое разграничение. На работе есть серьезная базка, я видел с десяток раз ее админский модуль, там конечно чего тока нет, видел как админ права (у меня на работе это никак по другому не называется :-)) раздает и т.д. Покапатся в нем мне ессенно не дают, поэтому вникнуть чего там у меня не получилось. Вот и решил узнать тут.

> > отсюда можно сделать один вывод если у меня будет 50 операций,
>
> > то мне понадобится 50 кнопочек, если порядка 500 как
> в
> > той БД которую я видел, значит нужно 500 =)
>
> Неправильный вывод. Завести 10 пользователей - это одна
> или 10 операций? Операций-то 10, но они однотипные и здесь
> достаточно одной кнопки. Ввести роль - еще кнопка. Дать
> полномочия на роль пользователю - еще одна кнопка. И дать
> полномочия роли или пользователю на выполнение хранимой
> процедуры, просмотр вьюхи и т.п. еще одна кнопка. Итого
> 4 кнопки! Реально, конечно, потребуется еще чего-нибудь,
> но я не думаю, что ты выйдешь за границы полутора-двух
> десятков кнопок, но это же не 500! И никаких переделок админмодуля.
>
> Естественно в качестве кнопок может выступать кто угодно
> (кнопки, таблицы, списки и пр.)

Вывод как раз правильный =), я не сказал про пользователей, а про операции типа:
- оборотная ведомость
- выписка из лицевого счета
- оборотно-сальдовая ведомость
- оборотно-сальдовая ведомость с разбивкой по периодам
- и т.д. 50 штук
Мне предлагали для каждой такой операции сделать кнопочку

> > мне прийдется написать администратору шпору с SQLем, типа
> напишешь эту команду и пользователь сможет выполнять
> > такие операции...
>
> не придется, если ты эти sql команды "подвесиш" на кнопочки,
> либо на > "нужных описаниях (типа "Проводка материальных
> счетов")"

> Sergey13 © (13.12.05 16:35) [17]

Ну я то хочу сочитать оба пункта, а вот как получится на самом деле =)

> Anatoly Podgoretsky © (13.12.05 16:38) [18]
> Учитывая заявленый зоопарк (IB6.x, MSSQL, MySQL, dBase,
> FoxPro, Paradox), про штатные средства, да и вообще можно
> забыть.
> Надо снизить аппетиты и определиться с минимумом.
> Последнии тру СУБД практически беззащитны.

Написано все это было для того, чтобы найти нужную СУБД, т.е. м.б. некоторый чел написал бы бери MSSQL там все это делается 2-мя командами =)
Пока мне фсе равно какая СУБД.

С самого начало было интересно кто, как и где хранит эти самые права пользователей, ну т.е. делает ли дополнительные таблицы в БД или наборы как в [4] или еще что-то.

Кстати никто так и не высказал своих соображений по поводу второго абзаца исходного вопроса - это кто нить как нить реализовывал?

в серверных субд все все равно делается SQL командами просто, все реализовано кнопочками. Типа
GRANT SELECT ON table1 TO user1 AS Accounting

> это кто нить как нить реализовывал?

кАнЫчнА!

> Вывод как раз правильный =), я не сказал про пользователей,
> а про операции типа:
> - оборотная ведомость
> - выписка из лицевого счета
> - оборотно-сальдовая ведомость
> - оборотно-сальдовая ведомость с разбивкой по периодам
> - и т.д. 50 штук
> Мне предлагали для каждой такой операции сделать кнопочку

Вывод неправильный. Операции ты эти чем будешь реализовывать? Я делаю через хранимки, кто-то предпочитает вьюхи - разницы (в администрировании) никакой. Для хранимки: grant execute on <ProcedureName> to <UserName | RoleName>; для вьюхи: grant select on <ViewName> to <UserName | RoleName>; И никаких 50 штук кнопок, всего одна. Единственное, что надо будет все же сделать, это создать свою табличку, в которой будет соответствие имени процедуры или вьюхи какому-то осмысленному комментарию.

> т.е. м.б. некоторый чел написал бы бери MSSQL там все это
> делается 2-мя командами =)
> Пока мне фсе равно какая СУБД.

Да никто не даст тебе верного однозначного совета. И двумя командами это не делается нигде. Я пишу сейчас на Oracle, раньше на MSSQL. Oracle мне нравится больше. Но это не значит, что теперь я должен всех ориентировать на Oracle. Oracle надежнее, но дороже и сложнее для понимания. Что выберет твое руководство? Что для него важнее? Надежность или дешевизна? Собирай плюсы и минусы по каждой из претендующих на покупку СУБД и решай с руководством, что вы можете себе позволить, а с чем мириться не согласны.

Реализация системы доступа и АРМа Администратора доступа. Найти похожие ветки