Практическое ограничение на количество входов в SQL Server? - PullRequest
1 голос
/ 08 марта 2009

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

Приложение использует один логин SQL Server для аутентификации, так как все права определяются данными самого приложения. Этот механизм плохо работает с отчетами, поскольку такие клиенты, как Crystal и MS Office, не проходят проверку подлинности через приложение (веб и WinForms).

Традиционный подход к использованию учетных записей SQL Server и пользователей базы данных будет работать, но может иметь одну проблему. В некоторых реализациях приложения количество пользователей, которые запускают отчеты и должны быть однозначно идентифицированы, может исчисляться сотнями.

Существуют ли какие-либо практические ограничения на количество входов в систему или пользователей в базе данных SQL Server (v 2005+), где такой подход может вызвать проблемы? Приложение может автоматизировать администрирование пользователей на сервере базы данных, но потенциальное количество учетных данных может быть проблемой.

Мы изучили методы олицетворения пользователей, но их становится трудно реализовать, когда клиент отчетов, такой как Excel, проходит проверку подлинности непосредственно на сервере.

Редактировать: Проблема не в параллелизме или рабочей нагрузке, а в проблемах администрирования в удаленных случаях, когда локальный администратор базы данных недоступен, особенно когда сервер не выделен для приложения. Интересуют сценарии, где количество входов в систему было проблематичным.

1 Ответ

1 голос
/ 09 марта 2009

Я использовал ваш описанный подход (учетные записи SQL Server автоматически управляются нашим приложением), и у нас не было никаких проблем. Тем не менее, у нас было максимум 200 учетных записей SQL. Но мы не столкнулись с какими-либо административными издержками, за исключением случаев, когда «опытные пользователи» восстанавливали базы данных, не сообщая нам, что приводило к тому, что учетная запись входа в SQL не синхронизировалась с базой данных *.

Я думаю, что ваш подход обоснован.

РЕДАКТИРОВАТЬ: Нашим решением для этого был процесс, который просто просматривал учетные записи пользователей и вызывал наши процедуры, которые удаляли / создавали учетные записи пользователей. Когда опытные пользователи назвали этот процесс, все было хорошо, и это было достаточно быстро.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...