C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

Re[4]: ADO.NETについて

分類:[C#]　

開発環境：.NET2008 C#

ADO.NETについて、質問があります。
よろしくお願いします。

よく簡単なサンプルなどを拝見すると下記のような手順が多いと思います。
1.Connection接続
2.Adapterを使用し、DataTableにSet
3.DataTableを編集
4.CommandBuilderで、Adapter.Updateを実行し、DBに反映
5.Connection切断及び、各オブジェクト破棄

ここで疑問と自分の見解です。

【疑問】
　すべてアクション(DB更新や、削除など)に、Connection接続・切断を行うと
　パフォーマンスに影響あるのではないでしょうか？
【見解】
　Connectionは、全体で１個保持し、すべてのアクションにて共通で使用します。
　APP終了時に、切断し破棄します。

【疑問】
　起動時に、Selectコマンドを設定したAdapterを使用し、すべてのテーブルからDataTableにSetしています。
　その後は、そのDataTableを使用し、DB更新を行っています。

　まず、Adapter＋CommandBuilderにおいて、更新・削除をするのには、Selectコマンドを設定する必要があると思います。
　更新・削除するのに、わざわざSelectコマンドを設定する必要があるのでしょうか？
　起動時に使用したAdapterを使用できないものでしょうか？
【見解】
　起動時に使用したAdapterを、テーブル数分、クラスにて保持しておき、
　更新・削除する場合、このAdapterを使用する。

以上、この考え方は間違っていますでしょうか？

>【見解】
>　Connectionは、全体で１個保持し、すべてのアクションにて共通で使用します。
>　APP終了時に、切断し破棄します。

「データベース接続は、必要となった時点で開き、使い終わったらすぐに閉じる。早く開き、呼び出しをまたいで開いたままにしてはなりません。」
http://msdn.microsoft.com/ja-jp/library/ms998569.aspx#scalenetchapt12_topic12

>【見解】
>　起動時に使用したAdapterを、テーブル数分、クラスにて保持しておき、
>　更新・削除する場合、このAdapterを使用する。数分、クラスにて保持しておき、
>　更新・削除する場合、このAdapterを使用する。

デザイン時に型付DataSetを作成すると、テーブル数分のAtapterが作成される。
更新・削除する場合、このAdapterを使用する。
# 実行時に CommandBuilder を使用するのはコストが高い

■No52365 (Masaking さん) に返信
> 　すべてアクション(DB更新や、削除など)に、Connection接続・切断を行うと
> 　パフォーマンスに影響あるのではないでしょうか？
コネクションプーリングという機構があります。

これは、切断された接続をしばらくは維持しておき、同じ接続文字列に対しては
以前の接続を再利用するというもので、二回目以降の再接続を高速化する働きがあります。
(接続先によっては、この機能を備えていない場合もあります)

プールされた接続が無い場合には、新規に接続が行われますし、
一定時間接続が無い場合には、プールされた分は破棄されます。

なお、プーリングはサーバー側で行われている場合もあれば、ミドルウェア
(OLE DB 層や ODBC 層など)で行われる場合もあります。また、多くの場合は
自動でプーリングが有効となりますが、データベースによっては、意図的に
プール機能の On/Off を指定できる物もあります。

コネクションプーリングの有無による再接続コストの例：
http://d.hatena.ne.jp/gsf_zero1/20070812/p4

> 　Connectionは、全体で１個保持し、すべてのアクションにて共通で使用します。
> 　APP終了時に、切断し破棄します。
そのような実装も間違いでは無いと思います。
たとえば、大量のデータを夜間に一括処理するような場合には、
一つの接続を維持し続けた方が効率が良いでしょう。

しかしユーザーが画面からデータ操作をするようなアプリケーションでは、
通常、データ編集に数秒～数分以上の時間を必要とします。また、その間も
接続を維持するためには、幾許かのリソースを必要とするという事情があります。

そのため、先述のコネクションプーリングを利用する事で、編集はオフラインで
行い、本当に必要なときだけ接続するという手法も多く利用されています。

> 　まず、Adapter＋CommandBuilderにおいて、更新・削除をするのには、Selectコマンドを設定する必要があると思います。
> 　更新・削除するのに、わざわざSelectコマンドを設定する必要があるのでしょうか？
> 　起動時に使用したAdapterを使用できないものでしょうか？
そういった事も可能です。

また、2005 以降においては「TableAdapter」を使うことで、DataAdapter を
デザイン時に作成しておくこともできます(型付 DataSet と共に使われることが多いです)。

この TableAdapter を使った場合、更新に必要な主キー情報や UpdateCommand 等を
事前に定義しておけるため、実行時に CommandBuilder を使うよりも実行効率が良くなります。

■No52370 (todo さん) に補足
> 「データベース接続は、必要となった時点で開き、使い終わったらすぐに閉じる。早く開き、呼び出しをまたいで開いたままにしてはなりません。」
> http://msdn.microsoft.com/ja-jp/library/ms998569.aspx#scalenetchapt12_topic12

その文言が記載されているのは、
　#scalenetchapt12_topic12 『パラメータ』
ではなく、
　#scalenetchapt12_topic6 『設計上の考慮事項』
の「遅く確保して早く開放する」の項ですね。

なお、接続プールについての情報は、同ページ内の
　#scalenetchapt12_topic9 『接続』
の項に記載されています。

訂正ありがとうございます。

第 12 章「ADO.NET パフォーマンスの向上」
http://msdn.microsoft.com/ja-jp/library/ms998569.aspx

ADO.NETを使う上では必見です。

todo様　魔界の仮面弁士様

遅くなってしまって申し訳ありません。
あらためて、返信ありがとうございました。

> 「データベース接続は、必要となった時点で開き、使い終わったらすぐに閉じる。早く開き、呼び出しをまたいで開いたままにしてはなりません。」
> http://msdn.microsoft.com/ja-jp/library/ms998569.aspx#scalenetchapt12_topic12
拝見しました。
とても、解りやすい内容で、ADO.NETにおいて、今後、参考にさせてもらいます。

>> 　Connectionは、全体で１個保持し、すべてのアクションにて共通で使用します。
>> 　APP終了時に、切断し破棄します。
>そのような実装も間違いでは無いと思います。
>たとえば、大量のデータを夜間に一括処理するような場合には、
>一つの接続を維持し続けた方が効率が良いでしょう。
>
>しかしユーザーが画面からデータ操作をするようなアプリケーションでは、
>通常、データ編集に数秒～数分以上の時間を必要とします。また、その間も
>接続を維持するためには、幾許かのリソースを必要とするという事情があります。
>
>そのため、先述のコネクションプーリングを利用する事で、編集はオフラインで
>行い、本当に必要なときだけ接続するという手法も多く利用されています。
>
>> 　まず、Adapter＋CommandBuilderにおいて、更新・削除をするのには、Selectコマンドを設定する必要があると思います。
>> 　更新・削除するのに、わざわざSelectコマンドを設定する必要があるのでしょうか？
>> 　起動時に使用したAdapterを使用できないものでしょうか？
>そういった事も可能です。
>
>また、2005 以降においては「TableAdapter」を使うことで、DataAdapter を
>デザイン時に作成しておくこともできます(型付 DataSet と共に使われることが多いです)。
>
>この TableAdapter を使った場合、更新に必要な主キー情報や UpdateCommand 等を
>事前に定義しておけるため、実行時に CommandBuilder を使うよりも実行効率が良くなります。

状況により、使い分けてもOKとのことですが、
ご教授頂いた、「コネクションプーリング」と「TableAdapter」を使用するのが一番良い方法だと解りました。

これで、疑問も払拭し、迷わず開発に取り組めます。
本当にありがとうございました。

C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

Re[4]: ADO.NETについて

過去ログには書き込み不可