Limite pratique au nombre de connexions SQL Server?

Question

Utilisation d'une application devant fournir une sécurité au niveau des lignes et des colonnes pour les rapports utilisateur. La logique pour le filtrage de ligne d'un masquage de colonne est en place, mais il reste des décisions à prendre pour identifier les utilisateurs au moment de l'exécution du rapport.

L'application utilise un seul login SQL Server pour s'authentifier, car tous les droits sont pilotés par les données dans l'application elle-même. Ce mécanisme n'est pas adapté aux rapports, car les clients comme Crystal et MS Office ne s'authentifient pas via l'application (web et WinForms).

L'approche traditionnelle de l'utilisation des connexions SQL Server et des utilisateurs de base de données fonctionnera avec la volonté, mais peut avoir un problème. Dans certaines implémentations de l'application, le nombre d'utilisateurs qui exécutent des rapports et doivent être identifiés de manière unique peut atteindre des centaines.

Existe-t-il des limites pratiques au nombre de connexions ou d'utilisateurs sur une base de données SQL Server (v 2005+) où cette approche peut poser des problèmes? L'administration des utilisateurs sur le serveur de base de données peut être automatisée par l'application, mais le nombre potentiel d'informations d'identification peut poser problème.

Nous avons examiné les techniques d'emprunt d'identité de l'utilisateur, mais elles deviennent difficiles à implémenter lorsqu'un client de rapport tel qu'Excel s'authentifie directement auprès du serveur. Le problème n'est pas la concurrence ou la charge de travail, mais plutôt les problèmes d'administration sur les instances distantes où un DBA local n'est pas disponible, en particulier lorsque le serveur n'est pas dédié à l'application. Intéressé par des scénarios où le nombre de connexions était problématique.

Answer 1

J'ai utilisé votre approche décrite (comptes SQL Server gérés automatiquement par notre application) et nous n'avons eu aucun problème. Cependant, nous avons seulement eu un maximum de 200 comptes SQL. Mais nous n'avons subi aucune sorte de surcharge administrative, sauf lorsque les «utilisateurs expérimentés» ont restauré les bases de données sans nous le dire, ce qui a provoqué une désynchronisation du compte de connexion SQL avec la base de données *.

Je pense que votre approche est saine.

EDIT: Notre solution pour cela était un proc qui a simplement couru à travers les comptes d'utilisateurs et a appelé nos procs qui ont supprimé/créé les comptes d'utilisateurs. Lorsque les utilisateurs de pouvoir appelaient ce proc tout allait bien, et il était raisonnablement rapide.