Роль приложения SQL Server, снижение производительности - PullRequest
Новая
       17

Роль приложения SQL Server, снижение производительности

8 голосов
/ 19 октября 2008

Я планирую использовать роли приложения MS SQL Server 2005 в своем приложении. Я начну роль с выполнения sp_setapprole и завершу выполнением sp_unsetapprole SP. Приложение реализовано в ASP.NET.

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

Я планирую позвонить sp_setapprole в начале всех моих SP и позвонить sp_unsetapprole в конце всех моих SP.

Использовали ли вы роли приложений SQL? Какие у вас XP? Что насчет производительности?

Ответы [ 2 ]

0 голосов
/ 20 октября 2008

Я прокрутил свое собственное "одобрение" в прошлом, это не слишком сложно. Создайте роль базы данных для каждого типа пользователя (менеджер, кэшер, клерк и т. Д.). Создайте пользователя базы данных с именем группы (manager_user, casher_user, clerk_user и т. Д.). Создайте учетные записи для ваших реальных пользователей и поместите их в роли базы данных. Проверьте пользователей asp.net, войдя в базу данных (откройте и закройте соединение), таблицу поиска или best , если вы используете проверку подлинности Windows и просто получаете их имя пользователя из IIS. Проверьте их членство в роли базы данных, но войдите в базу данных, используя role_user. Вы можете защитить объекты базы данных с помощью role_user, пользователи не входят в систему и не имеют доступа к каким-либо объектам sql, и вы получаете пул соединений.

0 голосов
/ 19 октября 2008

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

Однако в документах говорится, что начиная с SQL Server 2005 существует способ запомнить исходный контекст безопасности в виде файла cookie, возвращенного из sp_setapprole, и после этого использовать sp_unsetapprole, чтобы вернуться к нему. Таким образом, объединение должно работать снова. На твоем месте я бы сравнил перф. с парой простых утверждений / sprocs.

По какой причине вы не используете стандартный API-членство ASP.NET на уровне приложения вместо ролей приложения?

...