(1) Oracle でデータセット – 前振り
私の生業は、北海道の片田舎で SI ベンダーの下請けがメインとなっているんですが。
北海道の SI 事情としては、DB は Oracle が主流なんです。…私の体感としては。
SQL Server とか MySQL とかもちらほら耳にしますが、やはり Oracle の案件の引き合いが圧倒的なんですよ。
このへん、やっぱり VB6 ＋ oo4o の実績がモノをいうんですね。
SI はリプレースが多い、しかもまるっとではなく複数のシステムの一部のみとか、外部システムなどとの接続要件は一切変えずに社内システムのみとかの差し替え案件が多いので、「今動いている実績あるアーキテクチャはなるべく変更したくない」と思うのは人情なわけです。
ということで、勢い VB.NET ＋ ODP.NET という要件になりがちです。
実際には、VB6 と VB.NET は考え方から違いますし、oo4o と ODP.NET も同列には語れないものなんですが、それぞれ「後継」ということで、なんとなく安心しちゃうのもまた人情なわけです。
とはいうものの、プログラマサイドとしては、そんな なんとなく安心 では済まされません。
正確に、的確に、ひとつひとつ具体的に作っていかないばプログラムとしてまともに動かないからです。
VB2005 の時に、コードではなくウィザード / ビルダを使って生産性の向上を目指した「データセット」というオブジェクトというかリソースというかなんかそんな感じのものが提供されました。
手っ取り早く言えば、手っ取り早く DB アクセスできる モノ が使えるようになったんですね。
それに呼応して Oracle からも、Oracle Database 10g 用に、コードで制御する ODP.NET (oo4o のような使い方をするミドルウェア) だけではなく、ODP.NET 経由でデータセットを扱えるアドイン ODT が提供されました。
ところがこの ODT、実際には サーバーエクスプローラなどが VS IDE とは別に独自提供されたり、どうも動作が怪しげで変なエラーが出る、資料が少なすぎて調査もできないという、なんとも信頼できず使いにくいものだったんです。
当時私はこのへんにずいぶん悩まされました。
高生産性をあきらめて ODP.NET をコードから制御する古式ゆかしい手法を採ろうかとも思ったんですが、その時の案件が予算も期間もアレだったので、結局 Microsoft から提供されていた .NET Framework Oracle 用データプロバイダ (System.Data.OracleClient) ＋データセットを採用しました。
元請さんには「Oracle 純正じゃないのかい…」とシブい顔をされましたが、キモチ的な安心のためにアーキテクチャ選定の段階からデスマ確定、なんて事態は避けたかったので、そりゃあもう必死で説得したのも今ではいい思い出です。(＾＾；)
さて時は流れ。
VB も 2008 となり、11g 用の ODP.NET / ODT も提供されました。
11g 用 ODT は VS IDE との親和性も高くなり、動作も安定し、機能もかなり充実してきました。
正直、SQL Server ＋ データセットとほとんど変わらない操作性なので、うっかりするとどっちを使っているのか分からなくなってくるくらいです。
SQL 文の Oracle 方言でワーニングが出て、改めて「ああ、今オレは ODT 使ってたんだっけ」とか思い出したり。
VB2005 ＋ ODT(10g) の時の使いにくさも不安定さも感じられず、そろそろ現場でさくさくツカエるように思えます。
ということで、少し検証＋備忘録代わりにまとめていこうかなーと。
ちなみに。
ODT(11g – 11.1.0.6.20) は、2008/1/24 に提供開始されています。そんなもんをなんでこのタイミングでお話しするのかというと、私がコーディングと関係ない仕事をここ 1 年半ほどやっていて、調べる暇も動機もありゃしなかったからです。
もうひとつ。
正直、私は VB.NET (というか .NET 系開発言語全般)は、VB6の頃よりも製造作業に時間がかかると思っています。
VB6 ではコマンドを直接記述すればよかった、プロシージャ – モジュール – プログラム全体の 3 種類でスコープを考えればよかった、文法自体も量が少なく全体の把握に時間がかからなかった等々。
それに対し、.NET 系はクラス主体で構成をイメージしないとあちこちでつじつまが合わなくなる、メソッドは原則クラス経由で提供されるので常にインスタンスを意識しなければならない、スコープも宣言の書きどころでかなり微妙な有効範囲を取り得る、バージョンが上がるたびに新しい概念が追加されて学習量が増大する等々、同じことをするのにより時間がかかる 仕様になり続けています。
だから .NET はダメだ、などと短絡的な結論を出すつもりはありませんが、少なくとも VB6 の作り方を踏襲して VB6 の頃の感覚で工数を積むと全然足りなくなってしまいます。
コーディングをより丁寧に時間をかけて作らなければならなくなった分、どこかで時間を稼がないと単に 製造に時間のかかる効率の悪い言語 にしかなりません。
という背景からコードスニペットやらインテリセンスやらの ルーチンワークにかかる時間を短縮する機能 が提供され始めたんだと私は思っているんですね。
製造の現場では「使っても使わなくてもいい」みたいな軽い扱いをされることが多いんですが、趣味ならともかく業務として予算・時間の枠の中でモノを作っていくのであれば、この 同じ効果をより短い時間で実装する 機能を使いこなせるスキルはプロとして(もっと正確に言うと、プロジェクトまたは会社の方向性として)重要だと思います。
で、今回お話ししたい データセット も、私は生産性を向上させるためのツールだと捉えたいんです。
従来のコーディングによる DB アクセスをすべて手で書こうとすると、まず取得データの受け渡し用の構造体フィールドの型を参照しながら作り、抽出・挿入・更新・削除用の SQL 文をそれぞれ組み立て、データと構造体をそれぞれ紐付けるコードを記述する必要があります。
私の場合、この手のコードはそれこぞ VB2 ＋ Btrieve の頃からさんざん書いてきました。単純なマスタ単独アクセスを除くと、1 セット書くのに体感としては平均 2 時間程度かかるように思います。しかもどうしても引き写しミスの可能性があり、それぞれのアクセス機能に対してフィールド単位での検証作業まで考えると 4 時間くらいは見越しておかないとあっという間にスケジュールが焦げていきます。
対して、ウィザード等を使ってデータセット(この場合は正確にはTableAdapterになりますが)を作ると、長くても 15 分程度で同等の機能を生成することができます。
時間がかかりすぎるので今回はパス、などと機能の一部が省略されることもありません。悲観的排他は無理ですが、楽観的排他であればチェックボックスひとつで簡単に設定できます。DB の構成そのものを直接取り込んでデータ構成を生成しますので、引き写しミスもありません。ということは、動作検証の時間まで大きく短縮されることになります。
頭が固い、とは言いませんが、コーディング能力の高い≒自分のコードに強い信頼を持っている人ほど、なんでもコードで書こうとする傾向があります。
確かに書いたものが書いたとおりに動作する、書いていないものは動作しない、という点において、100% 自分で書いたコードはもっとも視認性も高く信頼性も高いと思うんでしょうね。
これを裏返すと、えてして自分の書くコードに自信を持っている人ほど、ウィザードなどによるコードの自動生成(データセット関連のウィザードも、一連のコードの自動生成が実体です)に対して懐疑的なスタンスを取りがちです。いわく「何やってんだかわからないコードは不安だ」「自分でコード書いた方が早い」いや、お気持ちは大変よくわかるんですが。私も一人で全部やるなら同じことを言うかもしれませんが。
しかしチーム全体で考えた場合、自分の書いたコードを完全に理解している、というメンバーばかりではないという状況はままあります。というか、むしろコードの意味をよくわからずにパターンの組み合わせだけでどうにか動くものを書くのが精いっぱい、ってメンバーのいないプロジェクトの方が珍しいと思います。
であれば、チーム全体としての生産性と品質の底上げという意味でも、データセットは有用なツールだと思います。
SI、というかサーバ – クライアント型のシステムを作る場合には、やはり DB アクセスのためのコーディングと検証のウェイトは大きいです。ので、ここが軽減されるのであれば、何としてでも採用したい。一部制限があったり不安定さがあるのであれば、そこを把握し回避するという条件付きでも採用するメリットは大きいですよね。
10g の頃の記事ですが、ODP.NET / ODT 他の構成と概念を把握したいなら、
Oracleにおける.NET開発環境の概要（1/4） － ＠IT
のあたりがいい感じですよ。