連載：VB研公開ゼミ議事録 第7回　ADO.NET開発初心者の疑問、解決します！ デジタルアドバンテージ　一色 政彦 2008/10/07

Page1 Page2

　現場で働くVisual Basic開発者のためのセミナー「VB研公開ゼミ」の第7回が、2008年9月6日（土）に開催された。このVB研公開ゼミは、＠IT／Insider.NET内に設置されているコーナー「Visual Basic業務アプリケーション開発研究室（略して『VB研』）」の主催により、3〜4カ月おきに定期的に開催されているものだ。

　今回は「VB開発者のための.NETデータベース入門」というテーマで、業務アプリケーション開発では避けて通れないデータベース処理について、基調講演およびパネル・ディスカッションが行われた。

第7回 VB研 公開ゼミ会場の様子

　基調講演では、「えムナウ」こと、児玉 宏之 氏にご登壇いただき、.NETのデータベース技術である「ADO.NET」の概念や使い方を基礎から説明していただいた。パネル・ディスカッションでは、ADOからADO.NETへの移行、SQL ServerとOracle Databaseの違いなどについて議論した。特にパネル・ディスカッションは、参加者から「現場の意見が多く、ほかのセミナーでは味わえない面白さがあった」というコメントが寄せられるなど非常に好評だった。

　今回のパネル・ディスカッションでは、以下の方々にパネラー／モデレータ（司会進行）としてご参加いただいた。

パネラー	児玉 宏之 氏（.Net ユーザーエクスペリエンス研究所／わんくま同盟） 福岡 寿和 氏（富士通ソーシアルサイエンスラボラトリ） 遠藤 孝信（＠IT／Insider.NETフォーラム編集長）
モデレータ	小川 誉久（＠IT／Windows Server Insiderフォーラム編集長）

パネル・ディスカッションの様子

　本稿ではこのパネル・ディスカッションの内容を要約してお伝えする。なお、パネル・ディスカッションでは非常に興味深い発言もたくさんあったが、一部の内容（製品の性能比較に関するものなど）は掲載できないため割愛している。実際のセミナーでしか聞けない面白い話もたくさんあるので、ぜひ次回のVB研ゼミでは聴講者としてご参加いただき、直接、現場開発者の生の声を聞いていただきたい。

　以下、敬称略。また、本稿では「アプリケーション」を「アプリ」、「Visual Basic 6.0」を「VB6」、「.NETに対応したVisual Basic」を「VB.NET」と略している。

■

■1. ADOからADO.NETへ移行する価値はあるのか？

――今回は事前に、参加者の皆さんに対してアンケート調査を行っており、多くの質問をいただいていますので、まずはその中から答えていくことにしましょう。

　「これまでVB6とADOを使ってきました。VB.NETにより開発されたWindowsアプリは、VB6によるものとあまり変わらないように思え、Webアプリを作るのでもなければ、.NETへの移行の価値を見いだせません。実際、ADO.NETへの移行は、どれほどの意味を持つのでしょうか？」

福岡　「VB6とVB.NETで作られるWindowsアプリは変わらない」という意見ですが、これはむしろメリットではないでしょうか。開発環境が変わると、違うものが出来てしまうのなら、逆に困ってしまいます。「成果物としては同じだが、中身は高性能でセキュリティ面にも強い.NETで動作し、かつ迅速な開発が行える」ことには大きな価値があると思います。

　ADO.NETだけを見ても、.NETへ移行する価値はあります。ADO.NETの専用プロバイダは、ADOに比べてパフォーマンスが非常に良いという印象を受けています。

児玉　「専用プロバイダ」というと、「データベースごとに実装方法が違って難しそうだな」と勘違いされる方がいるかもしれません。確かに、SQL Serverなら「System.Data.SqlClient」、Oracle Databaseなら「Oracle.DataAccess.Client」*1というふうに、それぞれ専用の名前空間が用意されていますが、これらの違いをラップして、共通的に利用できるようにしてくれるデータアダプタ（DataAdapterクラス）やテーブルアダプタ（TableAdapterクラス）というものが用意されています。これらを使えば、専用プロバイダの違いを意識することなくデータにアクセスできますのでご安心ください。

*1　ADO.NETでOracle Databaseを利用するには、オラクル社自身が提供する純正のODP.NET（Oracle Data Provider for .NET）、もしくはマイクロソフトが提供するOracleClient（.NET Framework Data Provider for Oracle）を使用する。ODP.NETは「Oracle.DataAccess.Client」という名前空間で、OracleClientは「System.Data.OracleClient」という名前空間でそれぞれ定義されている。OracleClientは.NET Frameworkに標準で付属するというメリットがあり、もう一方のODP.NETは、オラクル社自らが最新のOracle Databaseに合わせて最適化して作り込んでいるというメリットがある。

――なるほど。性能面なども良さそうだし、やはりADO.NETに移行すべきだなという印象ですが、ADO開発の資産を、ADO.NETでも活用できるのでしょうか？

.Net ユーザーエクスペリエンス研究所 ／わんくま同盟 児玉 宏之（えムナウ） Microsoft MVP for Visual C#

児玉　「できる」「できない」でいうと、ある程度できます。というのも、VB6開発で使われていたRDOやDAOなどを、.NETプログラムから呼び出すことも可能だからです（参考：「特集：VB6開発者が待ち望んだVB2005の便利機能　4. 新しくなったADO.NETのデータアクセス機能」）。

　ですが、この手法は.NETからCOM経由でのアクセスになるため、動作が遅くなるなどの問題があり、実際にこれを行うのはお勧めできません。現実的には、ADO.NETの仕組みに合わせて一から作り直していただくのが最善の手法です。

福岡　ADO.NET開発では、基本的には、いったんデータセット（DataSetクラス）にデータを読み込んで処理する仕組みになっており、VB6とはデータアクセスに対する考え方が異なりますから、そのままの移行はできないですね。ただし、SQL文に関する知識など、VB6で培った技術が活用できる場面もあります。

■2. ADO.NET開発初心者が気を付けるべき注意点

児玉　ちなみに、ADO.NETによるデータセットへのデータの読み込みでは、データはメモリ上に展開されるわけですが、例えば10万件を超えるような巨大なデータをデータセットに読み込んでしまうと、読み込み（Select）や更新（Update）が遅くなってくるというパフォーマンスの問題が発生することがあります。

　ですので、もちろん厳密には10万件という数値は状況により異なるわけですが、目安として10万件あたりを基準に「データセットをそのまま使うのか」「ほかの何らかの対策を行うのか」を判断することを、わたしはお勧めします。

福岡　確かに、全件をデータセットに読み込む「select * from XxxTable」のようなコードを.NET開発の初心者が書いてしまい、開発時には気付かないのですが、利用者が使い込むにつれて徐々にプログラムが遅くなってきて問題になってしまうということはあります。だから、ちゃんと条件指定（Where句）でデータを絞ってからデータセットに格納するような工夫が、ADO.NETを使う場合には必要になりますね。

――そのほかにも、ADO開発者が移行時につまずくようなポイントはあるのでしょうか？

福岡　ADO.NET開発では、接続型と非接続型という2種類のデータアクセス手法が提供されています。接続型とはアプリケーションの実行中はデータベースへの接続をずっと開いておく方法で、ADOでは一般的な手法でした。

　一方、非接続型とは、データベースを使うときにのみ接続を開き、使い終わったらすぐに切断する方法で、ADO.NETで導入された手法です。当然、接続型よりも非接続型の方がデータベースへの負荷が少なく、特に大規模システムでトラフィックが多い場合に向いています。せっかくですから、ADO.NETでは非接続型を使うべきだと思います。

会場　ADO.NETでも接続型が向いている場面はあるのでしょうか？

福岡　何らかの理由で、ユーザーの入力途中もずっとレコードのロックを維持する必要があるような場面では、接続型を使うとよいと思います。

会場　接続型ではDataReaderクラスを使いますが、名前があまりよくなくて、「参照系のときには、とにかくこれを使うべきだ」と勘違いしている人も多くいます。

福岡　DataReaderクラスはデータを更新できないので、確かに「参照系」という部分は正しいのですが、接続型なので1レコード読み込んでは、それを処理するといったようなコードを書かなければなりません（データセットに対応していません）。従って、特にデータセットの利用を想定しているグリッド表のコントロールを使う場合には向いていません。

児玉　接続型（DataReaderクラスなど）は、逐次読み込みをして逐次書き込みをするような場面には向いていますよね。

富士通ソーシアルサイエンスラボラトリ 第二産業流通ビジネス本部 主任 福岡 寿和 Microsoft MVP for Visual Basic

福岡　例えば、イントラネット内の業務データベースから公開Webのデータベースに毎日定時にデータを移動するようなバッチ処理があり、移動データの一部を加工しなければならないような場面ですね。

児玉　確かにバッチ処理を.NETプログラムとして組む場合にでは、接続型を使うことがよくあります。ちなみに、バッチ処理を（.NETプログラムではなく）SQL文として組む場合は、ストアド・プロシージャを使います。

会場　大量のデータの読み込みでは、非接続型のデータアダプタ＋データセットよりも、接続型のDataReaderクラスの方がパフォーマンスが良いと聞いたことがありますが。

児玉　その「大量」というのが、先ほど述べた「10万件のデータ」のことで、大量のデータに対して非接続型のデータセットを使うと、メモリを逼迫（ひっぱく）してパフォーマンスを低下させる恐れがあるので、そのような場面では接続型のDataReaderクラスを利用するのは1つの解決手段となります。逆にいえば、大量ではない、一般的なデータの読み取りであれば、非接続型を使うべきだと思います。

福岡　画面上のグリッド表のコントロールなどにデータを表示しないで、プログラム内部でデータを処理するだけであれば、接続型のDataReaderクラスの方がパフォーマンスが良いかもしれません。逆にデータを表示する場合は、表示するためのデータ構造をデータセットという形で.NET Frameworkが作ってくれるので、非接続型の方が良いです。

遠藤　ここまでの話では、

• データアダプタ＋データセットによる非接続型
• DataReaderクラスを中心とした接続型

の2種類があるという話ですが、大規模なシステム構築でよく採用されるN階層モデルでは、データアクセス層のコンポーネントがレコードを読み込み、（データセットではなく）独自のエンティティ・オブジェクトに格納し、それを各層間でやりとりするというパターンもあります。この際のデータアクセスでは接続型のクラスを利用することになると思いますが、この方式について何か意見はありますか？

児玉　その場合、エンティティ・オブジェクトは作らずに、データセットそのものを作成し、それをXMLにシリアライズして、各層の間で受け渡すことが可能です。ですので、非接続型で処理できます。

福岡　わたしの場合も、N階層システムの構築ではデータセットをXMLにシリアライズする手法を取っています。ただし、データアクセス層にはデータベースにアクセスするXML Webサービスを配置し、プレゼンテーション層となるWindowsアプリやWebアプリからは、そのXML Webサービスにアクセスしてデータセットを受け取るというパターンをよく採用しています。特に.NET Framework 2.0以降は、XMLへのシリアライズが非常に高速になっていますので、XML Webサービスを経由するこの手法でもパフォーマンス面にはまったく問題を感じていません。

　この手法が良いのは、データベースの近くで各種SQL文などのデータアクセス処理を一括して取り扱い、その処理結果として必要最小量のデータを入れたデータセットを作成できるので、アプリの性能が比較的向上しやすいことです。

　また、Webサービス化することで、データベースを操作するプログラムが局所化するので、1〜2人の技術力の高い優秀な開発者にその部分を任せることができます。データベース処理のパフォーマンスはSQL文の書き方などによる影響が大きいので、このように優秀な開発者に任せることは性能向上に役立ちます。

INDEX
	VB研公開ゼミ議事録
	第7回　ADO.NET開発初心者の疑問、解決します！
	1．ADOからADO.NETへの移行／ADO.NET開発の注意点
	2．ストアド・プロシージャについて／データベース・バージョンについて

「VB研公開ゼミ議事録」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）