SQL Serverログイン数の実際的な制限はありますか？

Question

ユーザーレポートに行および列レベルのセキュリティを提供する必要があるアプリケーションの使用。列マスキングをフィルタリングする行のロジックは用意されていますが、レポートの実行時にユーザーを識別することについて決定を下す必要があります。

すべての権限はアプリケーション内で駆動されるため、アプリケーションは単一のSQL Serverログインを使用して認証します。 CrystalやMS Officeなどのクライアントはアプリケーション（WebおよびWinForms）を介して認証されないため、このメカニズムはレポートにはうまくいきません。

SQL Serverログインとデータベースユーザーを使用する従来のアプローチは機能しますが、1つの問題があります。アプリケーションの実装によっては、レポートを実行し、一意に識別する必要があるユーザーの数が数百人に達する場合があります。

このアプローチが問題を引き起こす可能性があるSQL Serverデータベース（v 2005+）でのログインまたはユーザーの数に実際的な制限はありますか？データベースサーバーでのユーザーの管理はアプリケーションによって自動化できますが、資格情報の潜在的な数が懸念される場合があります。

ユーザーのなりすましの手法を検討しましたが、Excelなどのレポートクライアントがサーバーに対して直接認証を行うと、それらを実装することが難しくなります。

編集：懸念は同時実行性やワークロードではなく、特にサーバーがアプリケーション専用ではない場合、ローカルDBAが利用できないリモートインスタンスでの管理の問題です。ログイン回数に問題があるシナリオに興味がある。

Answer 1

説明したアプローチ（アプリケーションによって自動的に管理されるSQL Serverアカウント）を使用しましたが、問題はありませんでした。ただし、最大200のSQLアカウントしか持っていませんでした。しかし、「パワーユーザー」の場合を除き、管理上のオーバーヘッドは発生しませんでした。通知せずにデータベースを復元したため、SQLログインアカウントがデータベースと同期しなくなりました。

あなたのアプローチは健全だと思います。

編集：これに対する解決策は、ユーザーアカウントを単純に実行し、ユーザーアカウントを削除/作成したプロシージャを呼び出すプロシージャでした。パワーユーザーがこのprocを呼び出したとき、すべてが順調で、かなり高速でした。