Понимание снижения производительности роли приложения в SQL с помощью ASN.NET
Я использую роли приложения MS SQL Server 2005 в приложении. Я запускаю sp_setapprole, чтобы запустить роль SP и закончить sp_unsetapprole.
«пул соединений не работает» с пулом приложений, и нет возможности реагировать на соединение «отключение события» (выполнить sp_unsetapprole непосредственно перед отключением).
Я решаю вызвать sp_setapprole в начале всех своих SP и вызвать sp_unsetapprole в конце всех SP.
Вы использовали роли приложений SQL? Какие у вас XP? А как насчет хитов производительности?
Ответы 2
Раньше я не использовал роли приложений, но из того, что я знаю о перфомансе, следует, что после установки роли приложения нет возможности вернуться к предыдущей. контекст безопасности. Таким образом, соединение не может быть повторно использовано в пуле. Одно это уже огромная производительность. хит, который заставляет дважды подумать об использовании ролей приложения.
Однако в документации говорится, что, начиная с SQL Server 2005, существует способ запомнить исходный контекст безопасности в виде cookie, возвращаемого процедурой sp_setapprole, и после этого использовать процедуру sp_unsetapprole, чтобы вернуться к нему. Таким образом, объединение должно снова работать. На вашем месте я бы сравнил производительность. с парой простых утверждений / sprocs.
По какой причине вы не используете стандартный API членства в ASP.NET на уровне приложения вместо ролей приложения?
Мне пришлось проголосовать против этого ответа, потому что вопрос явно задает тех, кто имеет опыт использования ролей приложений. Также первый абзац излишне сбивает читателя с толку. Проблема пулов приложений решена с момента выхода SQL Server 2005. См. blogs.solidq.com/dsarka/…
Имейте в виду, что «решение», созданное в SQL Server 2005, не работает, когда вы живете в реальном мире: если ваше сетевое соединение разорвано, вы не сможете вызвать sp_unsetapprole.
Раньше я накатывал свой «април», это не так уж сложно. Создайте роль базы данных для каждого типа пользователей (менеджер, кассовый аппарат, клерк и т. д.). Создайте пользователя базы данных с именем группы (manager_user, casher_user, clerk_user и т. д.). Создайте учетные записи для своих реальных пользователей и поместите их в роли базы данных. Подтвердите своих пользователей asp.net, зарегистрировав их в базе данных (откройте и закройте соединение), в таблице поиска или в Лучший, если вы используете аутентификацию Windows, и просто получите их имя пользователя из IIS. Проверьте их членство в роли базы данных, но войдите в базу данных с помощью role_user. Вы можете защитить объекты базы данных с помощью role_user, пользователи не входят в систему и не имеют доступа к каким-либо объектам sql, и вы получаете пул соединений.
Извините, но мне пришлось проголосовать за эту статью. Это не ответ на вопрос. Скорее он предлагает альтернативу. Вопрос, в частности, требует ответов от тех, кто использовал роли приложений. Если нет, то вы не можете ответить на вопрос, поэтому, пожалуйста, не тратьте время других людей. Спасибо.
Я использую API членства в ASP.NET. Роль приложения SQL будет дополнительным уровнем безопасности