.net - SQL Server CE のローカル データベースで DataSet を使用する理由はありますか?

Question

アプリケーション データの永続化のためにローカルのインプロセス データベースを使用するアプリケーションでも、.NET DataSet を使用することに意味がありますか?

DataSet が主にデータベースの結果をメモリ内にキャッシュすることを目的としている場合、アプリケーションと同じプロセスで実行される SQL Server Compact ローカル データベースのようなものを使用する場合、あまり有益ではないように思えます。

型指定された DataSet を使用する他の理由はありますか? たとえば、それらは WPF データ バインディングを容易にしますか?

Answer 1

Let me try to answer my own question.

It seems to me that DataSets were designed for use-cases such as this:

1. Data is loaded from a remote DB to an in-memory cache (the DataSet).
2. The cached copy is operated on in non-trivial ways (multiple tables, delete, add, update) without an active connection to the database.
   • DB relations need to be modeled into the local cache to enable these operations.
   • Data binding to the UI (e.g., WPF) is trivial because we're working on in-memory copy of the data.
3. The cached copy is sometimes updated to the remote DB for true persistence.
   • This may happen for example when the client returns to online state or the user presses "Apply" to truly commit his data.

With local in-process databases, there's no need for the ability to work completely offline -- the local DB connection is always available. This would suggest that modeling (potentially) complex DB relations into the local cache to enable add, delete and update is unnecessary. Rather, one would directly modify data in the database and only maintain a custom local cache for viewing the data. The local cache could be decoupled from the DB layer and put into its own ViewModel layer (MVVM).

Answer 2

型指定されたすべてのデータセットをアプリケーションから削除しました。それらを作成するには時間がかかりすぎます。作成とは、新しいステートメント/コンストラクターを意味します。また、データの取得は、DataReaders を直接使用するほど効率的ではありません。

インプロセス データベースに (DataReader を使用して) 多数のクエリを実行すると、アプリの速度が大幅に低下するかどうかはわかりません。私はそれがあなたのアプリケーションに依存していると思います。

ほとんどの場合、追加の SQL ステートメントを解析して情報を取得するため、データをキャッシュする方が高速です。ただし、必要な追加のメモリにもコストがかかります。

Answer 3

SQL サーバー コンパクトを使用すると、SQL サーバーで動作するアプリケーションの単体テストを簡単に行うことができます。Sql サーバー コンパクトがない場合、テストは単体テストではなく統合テストになります (構成が難しく、実行に時間がかかります)。