1

アプリケーションにデータ ストレージ用の LocalDB を追加することを検討しています。

バックグラウンド：

1) 私のアプリケーションには 2 つの部分があります。を。デスクトップ クライアント。(コンピュータにログインしたユーザーで実行) b. NT サービス。(ローカル システムとして実行)

NT サービス: 1) クライアント固有の設定と構成オプションのために、バックエンド サーバーに Web サービス呼び出しを行います。
2) クライアントが作成したレコードをアップロードします。

デスクトップ アプリ: 1) NT サービスによってダウンロードされた設定を読み込み、それらの設定に従って実行します。2) クライアント レコードを作成します。

LocalDB はここに適しているように見えますが、これらの項目の両方が同時に LOCALDB にアクセスできますか? オンラインで調査した結果、LOCALDB 共有インスタンスが可能である可能性があるようです。しかし、それは NT サービスが常に LOCALDB 接続を維持しなければならないということですか?

4

1 に答える 1

2

あなたが説明したものと非常によく似た展開を行ったので、はい、これを行うことができます。しかし、私はそれに対して強くお勧めします。

いくつかの考え：

  1. LocalDB 'インスタンス' では、ユーザー プロファイルを読み込む必要があります。常にロードされる唯一の使用プロファイルは、ローカル システム、別名NT Authority\SYSTEMアカウントです。
  2. ' instance 'の所有者だけがそれを開始または停止できます。「automagic」インスタンスは、auto-showdown タイムアウトを無視するように設定できますが、少なくとも 1 回は開始する必要があります。ブート時に「 sqllocaldb start v11.0 」をシェルアウトするブートストラップを起動する Windows タスクを作成することで、これを解決しました。Windows タスクは「通常より下」のプロセス優先度で実行されるため、起動されたブートストラップは実際に、私のユース ケースでは SQLEnv.exe の優先度を高くしました。
  3. NT Authority\SYSTEMをインスタンス プロファイルとして使用すると仮定すると、SQL Management Studio などを使用すると、システム上で PsExec が必要になる可能性があります。これは、ローカル システムとして実行されるプロセスへの対話型アクセスを提供するため、セキュリティ リスクです。やらないでください。
  4. クライアント部分へのアクセスにグループを使用したため、これらのグループに実際のデータベース/インスタンスへのアクセスを許可します。それがなければ、新しいユーザーにインスタンス/データベースへのアクセスを許可することはほぼ不可能です。

データベースが本当に必要ですか、それとも、サービスが検査 (またはバッファーを作成) して途中で送信するレコードごとに、シック クライアントが特定の場所にファイルを書き出すことができますか?

もう 1 つの方法は、NT サービスを削除して、その機能をクライアントの起動プロセスの一部にすることです。構成の変更を常にチェックし、ユーザーがシステムをアクティブに使用している場合にのみデータをプッシュする、長時間実行されるプロセスがあるのはなぜですか? 要件/既存のシステムがないことを前提としています。

于 2012-07-21T22:27:24.960 に答える