Есть много разных способов решения этой проблемы.Поэтому многое зависит от архитектуры вашего приложения.
Как правило, вы создаете одну учетную запись базы данных, которая владеет объектами базы данных - таблицами, пакетами, представлениями и т. Д. Давайте назовем эту учетную запись BOOKSTORE_OWNER.Эта учетная запись обычно блокируется, чтобы никто не мог войти в систему как BOOKSTORE_OWNER другой во время периодических сборок.
Однако, помимо этой начальной точки, существует множество разумных способов справиться с аутентификацией и авторизацией.Если вы хотите, чтобы база данных работала с обоими, вы должны создать две роли - BOOKSTORE_USER и BOOKSTORE_ADMIN.Этим ролям будут предоставлены соответствующие привилегии для объектов, принадлежащих BOOKSTORE_OWNER.Затем вы должны создать пользователя базы данных для каждого человека, который может использовать приложение, и назначить соответствующую роль каждому новому пользователю.Поэтому, если вы являетесь администратором, а я - пользователем, учетная запись базы данных dygi будет создана и получит роль BOOKSTORE_ADMIN, а учетная запись базы данных Justin будет создана и получит роль BOOKSTORE_USER.
Этот подход работал довольно хорошо, когда люди создавали клиент-серверные приложения.Если вы используете трехуровневое приложение, с другой стороны, вы хотите, чтобы пул соединений среднего уровня использовал те же учетные данные для подключения к базе данных, а не для того, чтобы у каждого пользователя были свои собственные подключения к базе данных.Самый простой способ сделать это - создать одну учетную запись базы данных BOOKSTORE_APP, предоставить этой учетной записи все привилегии роли BOOKSTORE_ADMIN и BOOKSTORE_USER, а затем позволить приложению реализовать логику, чтобы выяснить, какой пользователь переднего плана имееткакие привилегии.Это обычно влечет за собой таблицы USER, PRIVILEGE и USER_PRIVILEGE в схеме BOOKSTORE_OWNER.Этот подход может работать довольно хорошо.Недостатком, однако, является то, что каждое приложение должно создавать свою собственную логику для управления привилегиями, которая со временем может стать довольно сложной.Это также может затруднить составление отчетов о том, какие привилегии имеют пользователи, или гарантировать, что привилегии пользователя будут обновляться, когда пользователи покидают организацию или переходят на новую роль.
В частности, Oracle обращается ко многим изэти проблемы, разрешив аутентификация прокси .Это позволяет сочетать преимущества подхода «клиент-сервер», когда каждый пользователь имеет свою собственную учетную запись базы данных, которая использует существующую инфраструктуру управления привилегиями Oracle с преимуществами пула подключений при использовании общей учетной записи базы данных.Это работает очень хорошо, но работает только с Oracle, а затем только с определенными протоколами (OCI и JDBC), поэтому он не очень популярен.
Конечно, помимо этих основ, вы можете столкнуться с некоторыми сложностями.Возможно, вы захотите иметь корпоративных пользователей , где Oracle не поддерживает пароль, а вместо этого позволяет пользователю выполнять аутентификацию на основе внешнего каталога LDAP.Возможно, вы захотите управлять привилегиями с ролями LDAP, а не со строками в таблицах для конкретного приложения.Возможно, вы захотите интегрироваться с различными решениями единого входа (SSO) среднего уровня.