один пользователь базы данных оракула или несколько пользователей, используемых в asp.net

У меня есть вопрос о производительности для каждого из этих двух сценариев в базе данных оракула: -

фон: я разрабатываю бизнес-приложение asp.net для корпоративной базы данных oracle

один:

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

два:

Я создаю несколько пользователей базы данных (от 2 до 5 пользователей) и использую их в пуле строк подключения, поэтому, если двадцать конечных пользователей одновременно используют приложение asp.net, то не все подключаются к базе данных как один пользователь

что лучше


person mustafak26    schedule 07.02.2013    source источник
comment
Не имеет значения, есть ли у вас двадцать сеансов от одного пользователя или двадцать разных пользователей с одним сеансом у каждого. Это звучит слишком мало, чтобы быть проблемой само по себе, но, возможно, все двадцать работают одновременно. Вы уже используете пулы соединений?   -  person Alex Poole    schedule 07.02.2013


Ответы (2)


Я не уверен в специфике Oracle ... но в целом хорошая модель выглядит следующим образом:

  1. Создайте несколько пользователей базы данных, каждый с разными уровнями доступа к базе данных, в зависимости от их роли. Эти пользователи БД не соответствуют реальным пользователям, вместо этого они соответствуют ролям, вероятно, около 4: полный доступ для создания/удаления/обновления таблиц и т. д., доступ для записи в таблицы обновления, доступ для чтения для выбора из таблиц, выполнение хранимых процедур и функций .

  2. Для любого изменения данных, которое требуется вашему приложению ASP.NET, инкапсулируйте эту операцию в хранимую процедуру. По сути, вы пишете интерфейс доступа к данным на уровне хранимой процедуры.

  3. Создайте пользователя db «stored_procedure_executor», доступ которого разрешает только выполнение определенных хранимых процедур (и функций). У этого пользователя НЕТ доступа к CREATE/DROP/UPDATE/SELECT непосредственно из таблиц.

  4. В вашем приложении ASP.NET вам нужно только сохранить/предоставить строку подключения (информацию для входа в базу данных пользователя) для учетной записи базы данных «stored_procedure_executor».

  5. Во время разработки, сопровождения, поддержки вам понадобится возможность СОЗДАТЬ/УДАЛИТЬ/ОБНОВИТЬ/ВЫБРАТЬ напрямую, а для этого вы можете создать дополнительных пользователей БД с соответствующим уровнем доступа. Но вы будете использовать эти учетные записи БД из инструментов управления БД, а не через ASP.nET. Таким образом, данные для входа никогда не нужно будет раскрывать на уровне ASP.NET.

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

person user2049524    schedule 07.02.2013
comment
это хорошо, но моя ситуация такова: я наблюдаю ухудшение производительности, когда 20 конечных пользователей запускают приложение одновременно, так что это потому, что я выполняю всю свою работу с БД как один пользователь БД или могу улучшить, используя несколько пользователей - person mustafak26; 07.02.2013

это хорошо, но моя ситуация такова: я наблюдаю ухудшение производительности, когда 20 конечных пользователей запускают приложение одновременно, так что это потому, что я выполняю всю свою работу с БД как один пользователь БД или могу улучшить, используя несколько пользователей ??? ?????????????????????

person mustafak26    schedule 11.02.2013
comment
Это должен быть комментарий или редактирование исходного вопроса. - person Branko Dimitrijevic; 11.02.2013
comment
Это не дает ответа на вопрос. Чтобы подвергнуть критике или запросить разъяснения у автора, оставьте комментарий под его сообщением — вы всегда можете прокомментировать свои собственные сообщения, и как только у вас будет достаточно reputation вы сможете комментировать любой пост. - person Jon Egerton; 11.02.2013