TolaniusПодскажите пожалуйста, как лучше поступать.
Разрабатывается некоторая система (СУБД Оракл 10g), в которой необходимо будет регистрировать, каким пользователем был создан/изменен то или иной документ, а также разграничивать некоторые полномочия на создание/редактирование документов и просмотр отчетных данных. В общем, стандартный набор...
Так вот, на каком уровне лучше заводить пользователей - как пользователя БД, или же создать специальную табличку пользователей и уже разруливать все полномочия на уровне этих "табличных пользователей" ???

Заранее благодарен

Если в СУБД Oracle, то тут есть одна тонкость - пользователь в Oracle равен схеме БД, а последняя разделяема физическими пользователями. Можно конечно насоздавать пустых схем для по одной на каждого пользователя и нараздавать гранты для доступа к некой "основной" (где-то по-моему на этом сайте была статья, но может ошибаюсь).
Но для целей журнализации и разграничения доступа может быть проще завести табличку пользователей с именами и фамилиями, ролями, правами и т.д, только тогда придется заводить и табличку журнала со ссылкой на измененный объект. И на уровне приложения управлять доступом.
Последний вариант IMHO удобнее для промышленных систем, так как позволяет завести осмысленные роли в контексте бизнес-логики, типа "Бухгалер", "Менеджер по продажам", "Операционист", "Администратор" и т.д. И регистрировать юзеров и раздавать права тога можно где-то в интерфейсе приложения.
Но мороки больше - получается дополнительная подсистема...

tru55CountZerro
Если в СУБД Oracle, то тут есть одна тонкость - пользователь в Oracle равен схеме БД, а последняя разделяема физическими пользователями. Можно конечно насоздавать пустых схем для по одной на каждого пользователя и нараздавать гранты для доступа к некой "основной" (где-то по-моему на этом сайте была статья, но может ошибаюсь).

Именно так и делается :))
Все остальное - "изобретение велосипеда", дублирование стандартного функционала.

PS
1. пользователь не равен схеме, он всего лишь имеет одинаковое с ней имя. Схема - это совокупность объектов, принадлежащих пользователю.
2. насчет пустой схемы - вопрос терминологический и несколько раз обсуждался на форуме Oracle. На мой взгляд, в связи с определением из п.1, пустой схемы не бывает (также, как пустого облака), но еще раз повторяю - вещь чисто терминологическая, главное, чтобы человек в этом не путался

Делается по разному - в больших системах таблица пользователей часто есть. Но правда надобно заметить, что эти так называемые "большие" системы часто просто мигрировали в Oracle с чего-нибудь типа Pervasive/Btrieve, поэтому в них много исторического мусора, и их брать за образец для подражания стоит с большой осторожностью.
А насчет "пустой" -да, согласен, "пустой" только в смысле отсутствия пользовательских таблиц и проч.

tru55_мод
Проблема в том, что права должны раздаваться на бизнес-объекты и бизнес-логику, а не на объекты БД. Т.е. необходим транслятор, а это уже сложно, если вообще возможно. Проще контролировать доступ на уровне приложения, но тогда возникает вопрос - сколько и каких пользователей надо регистрировать в БД - от 1 до N.

А еще при этом надо как-то контролировать, чтобы пользователь (вдруг он будет несколько более квалифицированный) не смог подключиться к базе не через приложение, а через какой-либо инструмент (SQL*PLus, PL/SQL Developer и проч.)

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

Можно конечно и из midlware проверять наличие и права пользователя БД, но это как-то уже...аннуально.

А полностью всем запрещать подключаться через инструмент тоже плохо - это может понадобиться например админу приложения (не обязательно равен DBA).