ADO使用か構造体等の使用か

質問

Excelでフォームを作って、そこからデータを吸い上げて保存用兼データ解析アプリケーションのデータ元となるようなCSVファイルへフォーム内容を書き込むというような、よくある操作を行うとします。

今までは、変数を宣言して配列を使ったり構造体を使ったりしていましたがデータベースを独学で学んでいるうちにVBAにもADOを使用したデータ操作が行える方法があることを最近知りました。

まだ、SQL的な書き方でものを作ったことが無いので実感が無いのですが上っ面だけ見ると細かく変数等を管理することが減るように思えるので今頼まれている内容にはADOを使用したものに挑戦してみようかと思っています。

経験者の方がいらっしゃいましたら、ADOを使用することの率直な利点と難点を聞かせてください。

回答No.1

noname#245936 · ベストアンサー

IT屋のものです。

当方は、超DB派です。
DB操作は慣れちゃうと簡単なので、何でもかんでもDBに入れたく
なり。何でもかんでも２次元データはDBやストアドプロシジャ
（Accessならアクションクエリ？）でロジック処理したくなります。

DBのメリットは
１．データが大量でも問題なし。1000万件でも大丈夫。
　　比較的高速。
２．検索系は、テーブル間結合とソートがとても便利。
　　ループ文を書かなくてよい。
３．更新・削除系は、条件付けが便利。
　　一行のSQLで複数行に影響を与えることができる。
４．排他制御がきっちりいくため、１つのデータを複数機械で
　　制御するようなシステムではそもそも必須。
５．業務ロジックがSQL側に移行されるので、ソースコードの中身が
　　画面処理だけになってメンテナンスがしやすくなる。
６．仕様の変更がしやすくなる。
　　たとえば、DBが ver.1、クライアントアプリもver.1として、
　　DBを互換のないver.2にしたとき、同時にクライアントもver.2に
　　しないといけないとすると、クライアントが100台いれば同時に
　　いっせーのーせで100台展開しないといけない。
　　そこをDBがわロジックで吸収できる。
７．安全性は確実に上。
８．データと、ロジックと、画面をModel View Controlで分けられる。
　　なので、１つのDBをVBで見たり、i-phoneで見たりと言った
　　ソフトを作るとき、各ソフトは画面制御＆通信実装のみでよい。

ま、SQLで何でもできちゃうので、慣れちゃえば無い生活はあり得ま
せんね（笑）

デメリットは…あえていうなれば。
１．DBエンジンが比較的容量的に大きい。
　　簡単なことをさせるにはオーバスペック。
２．足回りが重くなる。
　　ほかのPCに環境を持っていくとき、DBのインストールが必要。
そんな感じですね。
がんばってくださいね。

補足

早速のご返答ありがとうございます。

説明が足りずに誤解させてしまっているようですが、具体的なDBエンジンは考慮していません。あくまでもExcelのMicrosoft.jet.OLEDB.4.0を参照しての作業のみを考えています。

とはいえデメリットを見てみると、メリットを受けるには「DBエンジン」を使ってのことのようですが、限定的なのでしょうか？

回答No.4

noname#245936

No.1の者です。

しょうがない、概要を教えますと。
まず、SQLだろうが、Accessだろうが、やり方によってはOracle
だろうが、PostgreSQLだろうが、DBMS（データベースエンジン）を
使うには何をするにも、参照するのがADOというやつです。
VBなら、Microsoft ActiveX Data Object Library ver x.x。
実態は、msadodb.dllとか、単なるファイルセットなんですけどね。

で、旧のADOライブラリでは。（.NETはちょっと違う）
Connection … DBに繋ぐ、切る、アクセス権限、トランザクション
RecordSet　… SQLの結果データ（SELECT文の扱い）
Command　　… SQLのアクション (INSERT/DELETE/UPDATE)、
　　　　　　　アクションクエリ、ストアドプロシジャ
３つ知ってたらOKなのは周知のとおり。

で。
ローカルDBをAccess使う場合も、SQL Server使う場合も
接続文字列　Connection.ConnectionStringプロパティで繋ぎ変え
ます。
接続文字列は…ベタで書いてもいいけど、お客様の環境にもっていく
時などに、固定文字列だと取り扱い悪いので、僕の場合は、
Cn.ConnectionString = "FILE NAME=.\ApplicationName.udl"と書いて
拡張子「udl」というファイルを参照させます。
UDLファイルというのは、User Data Linking Fileの略で接続文字列
を覚えこませる専用のファイルです。

ためしに、テキストファイルを作成し、拡張子をUDLに変えてくだ
さい。変なアイコンになりますよね。で、ダブルクリックすると…
接続定義専用のウィザードがでます。
で、保存した後で、テキストエディタで覗くと。
…ご理解いただけたかと。

あとは、大体流れが決まっていて。
（バグってたらすまね）
Dim Cn as New ADODB.Connection
Dim Rs as New ADODB.RecordSet

Cn.ConnectionString = "File Name=XX.udl"
sql = "SELECT ほにゃらら FROM テーブル WHERE どこそこ"
Cn.Open
If Err.Number <> 0 Then Goto Err
rs.Open cn,sql,りーどおんりー,楽観ロック（書き方忘れた）
if rs.count < 1 then "結果があらへんがな処理"
do until eof
やりたいしょり
　TextBox1.Text = TextBox1.Text & fs.fields("商品名").Value &
vbcrlf
loop
rs.close
Cn.Close

こんな感じ。
どこぞのWebページでサンプルコードあったと思いますので。
こんなもんでご勘弁を。

お礼

勉強しながら解読するのに時間がかかりまして(笑)、返事が遅くなりすみませんでした。

先回の回答の意味を履き違えていたようです。

繋ぎたいDBごとということであって、データソースというわけではないのですね？

いろいろとありがとうございました。

回答No.3

noname#245936

No.1の者です。
う、用語に誤解ありますね。

ADOとは、Microsoft ActiveX Data Object Libraryの略で。
簡単に言うと、DBを操作するライブラリ。
プログラム部品のこと。

Microsoft.jet.OLEDB.4.0というのは、そのライブラリのなかの
実装機能の１つで、Accessのmdbファイルのデータベースを取り
扱うやり方のこと。
おなじADOでほかにも、SQL Server OLE DB、Excelなんとかなど。
接続したいDBごとに特化したADOオブジェクトライブラリがあります。

簡単に言うと、データベースを、オープン、SQLスロー、内容ゲット
クローズ…などを一連操作できるConnectionだのRecordSetだの、
あのプログラムの書き方のこと、参照オブジェクトのことで。
Connectionオブジェクトの書き方を変えれば、AccessでもSQL Server
でも繋げることができます。
ということですね。
（厳密には、DB毎に多少方言があるので、まったく同じソースコード
　で動かすのはちょっと難しいです。SQL文の方言や、機能面の方言
　があります。）

なお、余談ながら。
Accessの利点は、ファイルコピペで持っていけ、手軽であること。
（本当は昔のOSではADO自身をインストールする必要があったが、
　最近はOSに同梱されています）
また、自身でフォームや帳票を持っていること。

Accessの欠点は、排他アクセスに弱いこと。
（複数人が同時に同一データを変更をかける時の排他制御が機能
　的に弱くあいまい。たとえば全国から予約される新幹線の座席
　予約システムをAccessで作ると、きっとクラッシュするか、
　ダブルブッキングしてしまう。）
メンテナンスをしないと容量が肥大化する。
データの断片化が起こりやすく、メンテナンスなしでは遅くなる。
ま、所詮パーソナルユースであるということであります。

なお、SQL Serverのフリー版として、SQL Server Expressという
SQL Serverの簡易版がありまして。
こちらのほうがAccessより性能ははるかに上です。が。
Accessのようにごてごてした画面がないので、難易度もちょっと
上がってしまいます。

慣れないうちはAccessでいいと思いますよ。
ソフトは作ってみて、動かしてみて、動いてみて考えることが重要
ですからね。

補足

詳しくご教授していただきありがとうございます。

質問の内容としての回答は終わりかと思うのですが、一点気になりましたのでよろしければお付き合いください。

オブジェクトライブラリの内容については現在進行形で学習中でありますが、接続するデータソース別に特化したライブラリがあるというのは初耳です。

巷の教本では基本的にはMicrosoft ActiveX Data Object2.X Libraryを参照してからの作業についてしか書かれていません。

例えば、Excelブックやシートに特化、csvに特化となればどのライブラリにあたるのでしょうか？

＞Accessは排他アクセスに弱い。データの断片化。
それは当初現在の仕事を頼まれる際、把握しておりました。しかし、組織の中で個人で使用するシステムは中々考えられない。けれど、プログラミング始めたばかりの私にはSQLも同時に、ましてやオラクルにも足を出してみようかとは考えられませんでした。それもこれも一長一短とはいえ自身のスキルを考えると、ベースを何にするかはいつも悩みの種です＾＾；

＞SQL server Expressについて
いいですよね、Express版。個人仕様ではないけれども、そこまでスペックは要らないという規模の開発にはうってつけだと思います。私の部署はソフトウェアにお金を出すところではないのでなおさらです(笑）しかし、触ってみるとやはりというかそこそこ私には難解でした。あと一年くらいは経験が必要な気がしています。

回答No.2

Wendy02

こんにちは。
#1さんのおっしゃっていることでほとんどサポートしているように思えます。
特に、マイナス面で、

>１．DBエンジンが比較的容量的に大きい。
>２．足回りが重くなる。

は、Access以外で使うときは、いくら、事前バインディングしても、重く感じます。
つまり、Excelの場合は、如実に感じます。ですから、よほどデータベースとして大きなものか、CSVファイルをデータベースファイルに換えてしまうとかしなければ、一般的なに別のワークブックにして検索してしまったほうが早いような気がします。

>１．データが大量でも問題なし。1000万件でも大丈夫。
逆にいうと、～5万件ぐらいのレベルでは、Excel単独で処理しても、楽に扱えるように思うのです。

>メリットを受けるには「DBエンジン」を使ってのことのようですが
DBエンジンで、Jet を使うというなら Access という意味でしょうけれども、部分的に抜き出した機能を言うなら、メリット自体は変わらないと思います。

それと、SQL は、なれないと、どこでミスをしているのか分かりにくいです。

お礼

作業に踏み切るにあたってよい後押しになります。

どこをミスしているかわからないのは、当方VBでもさほど代わりませんので（笑）