本連載は、1998年4月号よりJetデータベースエンジンとSQL Server 6.5のパフォーマンスを比較することから始まった。SQL Server 6.5のベンチマークは使用許諾の関係で公表することができなかったが、両者のパフォーマンスは多くの場面で同等であり、いくつかの場面ではJetデーターベースエンジンがSQL Serverをわずかに上回った。ただ、テーブルスキャン（インデックスを使用しない検索）では、SQL Server 6.5がJetデータベースエンジンを大きく上回った。
このSQL Server 6.5とJetデータベースエンジンのパフォーマンスに差が少ない事実は、SQL Server 6.5にとって決して不名誉な結果ではない。SQL Server 6.5にはJetデータベースエンジンとは比較にならないほどの耐障害性があり、それを実現しながらも同等のパフォーマンスを発揮できるということが、その真価だからである。
また、前回のトラフィック量調査でもわかるように、ファイル共有型のデータベースエンジンであるJetデータベースエンジンは、ネットワークを使用してマルチユーザーで使用した場合、パフォーマンスが致命的に劣化する可能性がある。
1998年6月号「第3回 ファイルにアクセスするか、データベースにアクセスするか、それがWebサーバーとデータベースサーバーとの違いである」、1998年7月号「第4回 自作HTTPクライアントによる、データベースアクセス」では、Visual Basicを使ってWebサーバーとHTTPクライアントを作成した（図3・4）。データベース関連の記事でWebサーバーとHTTPクライアントについて解説したのは、「ファイル共有型のデータベースをクライアント／サーバー型のデータベースとして利用するためには、データの配信メカニズムが必要であり、その機能はWebサーバーと構造的には同じである」ということを明示したかったからである。
図4を見てもらうとわかるが、HTTPクライアントといってもWebブラウザではない。返信されたHTMLソースをそのまま表示しているだけである。図5は同じHTTPクライアントを使ってActive Server Pagesにアクセスし、データベースクライアントとして活用したものである。
図3：Webサーバーサンプル（リクエストを受け付けた状態）
図4：Visual BasicのWinsockコントロールを利用したHTTPクライアント
図5：Active Server Pagesを使ってHTTPクライアントからデータベースにアクセス
HTTPを使用するべきだったのかは、後悔するところだ。
Active Server Pagesはサーバー側でデータベースにアクセスし、HTTPクライアントにその結果を配信する機能をもつ。その機能をクライアント側から利用することで、IIS＋Active Server Pagesをデータベースサーバーとして利用しているのである。この方法は本誌1999年6月号の特集で掲載された拙稿「Visual Basicクライアントアプリケーションから、Transactional ASPを利用する」でさらに進化した方法を紹介している。
HTTPを使用する方法の解説は、第4回で終了する。これ以降は独自プロトコルを使用したデータベースサーバーの開発に進むわけだが、正直いえば、HTTPに被せるプロトコルを使用し、IISを利用する方法を推し進めていったほうが時代のニーズにあった結果を提供できたかもしれないという後悔も若干ある。しかし、独自サーバーを使用したおかげで、この連載の最大の収穫ともいえるVisual Basicによる完全なTCP/IPマルチスレッドサーバーを後に開発することができたので、よしとしよう。
データ転送が遅いデータベースサーバーは、やっぱり遅い
〜バリアント配列からテキストへ
1998年8月号「第5回 データ転送の高速化を実現」で発表したType2およびType3 DB Serverでは、データの転送にバリアント配列を使用していたのものを文字列に変更し、データ転送の高速化をはかった。当初バリアント配列を使用したのは、文字区切りなどの処理を省略することでプログラミングを簡略化するためだった。しかし、それによってパフォーマンスがかなり犠牲になっていることが判明したので、文字列によるデータ転送に変更したのである。Type3 DB Serverでは、大量の結果セットを転送する際、文字列を一括で転送せず分割して転送するように修正することで、更なる高速化を実現した。
マルチユーザーに本格的に対応。その秘密はActiveX.EXEコンポーネント
1998年9月号「第6回 マルチユーザーに対応し、並行処理可能のデータベースサーバー」で解説したType 4 DB Serverでは、マルチユーザーに完全に対応するため、アーキテクチャ上の大きな変更を行なった。データベースサーバーはマルチユーザーマネジメントサーバー（図6）とDBアクセスサーバー（図7）に分離され、DBアクセスサーバーはActiveX.EXEとして実装された。
マルチユーザーマネジメントサーバーは、単にユーザーからの接続を受けつけるためだけに存在する。クライアントからの接続要求がくると、マルチユーザーマネジメントサーバーはDBアクセスサーバーを起動し、クライアントの接続情報を渡した後で接続を切断する。
起動されたDBアクセスサーバーは、接続情報をもとにクライアントにコールバックし、クライアントがそれを受け付けた時点で接続が完全に完了し、データベースへのアクセスが可能になる。
Type4 DB Serverの問題点は、接続の仕組みが複雑なことと、接続あたりの使用メモリが極端に大きいことである。各接続ユーザーごとにマルチプロセスでDBアクセスサーバーを起動するため、メモリの消費がどうしても大きくなってしまう。しかし、データベースへのアクセスは各ユーザーごとに完全に分離されるため、複数ユーザーによるクエリーの同時実行に対応できるようになったのである。
図6：マルチユーザー接続を管理するマルチユーザーマネジメントサーバー（Type4 DB Server）
図7：各ユーザーごとのデータベースアクセスを担当するDBアクセスサーバー（Type4 DB Server）
1998年12月号「第9回 ADOのレコードセットを使用したクライアントの実装」で発表したType6 DB Serverからは、開発するツールをVisual Basic 6.0（以下VB6）にバージョンアップしている。VB6に新しく付属したADOのRecordsetオブジェクトを利用し、サーバーから受信した結果セットをクライアント側でRecordsetオブジェクトに格納した。その結果、クライアントのプログラミングで結果セットを扱うときに、文字列の切り貼りではなく汎用的なコードを記述できるようになった。データベースは単独で完結するものとではなく、必ずクライアントアプリケーションとセットで使用される。それを考えれば、クライアント側のプログラミング効率を上げるためにコンポーネントとして扱うことができることは重要である。
データ連結が可能になり、実用性のあるアプリケーションを開発
1999年1月号「第10回 Type7 DB Server−任意のテーブルからレコードセットを作成」では、VB6で新しくサポートされたデータ連結コントロールの作成機能を使用している。図8はグリッドコントロールとテキストボックスにデータを連結したフォームである。続く、1999年2月号「第11回 Type7 DB Serverを使ったクライアントアプリケーション」では、単にテスト用にデータを表示するだけではない実用性のあるアプリケーションを作成した。図9がその「著者情報検索アプリケーション」である。このアプリケーションではマスター詳細フォームを採用し、著者名を検索すると、その著作が表示できるようにした。結局、この「著者情報検索アプリケーション」が本連載で唯一実用性のあるアプリケーションになった。しかし、まだClient Libraryができる前なので、データベースアクセスのためのコードは抽象化されておらず、アプリケーションに埋め込まれている。
図8：グリッドへのデータ連結を行なったクライアント
図9：著者情報検索アプリケーション
マルチスレッド
1999年3月号「第12回 マルチスレッドSocketサーバーによる、データベースサーバーの実現」のType8 DB Serverでは、遂に完全なマルチスレッド化を実現する。Visual Basicがマルチスレッドアプリケーションの開発に対応していないことはご存知の方も多いと思う。その制限をクリアするには、いくつかの方法が考えられる。CreateThread API関数を使う強力な方法もあるが、Type8 DB Serverで採用したのは、ActiveX.EXEをマルチスレッドで使用する方法である。
ActiveX.EXEが別のプロセスで動作するActiveX.EXEコンポーネントだということはよく知られている。しかし、複数のActiveX.EXEのインスタンスを、COMクライアントとは異なるひとつのプロセス内で同時にマルチスレッドで動作させることができるということは、あまり知られていない。この方法を用いることで複数のDBアクセスサーバーをマルチスレッドでロードできる。そして、結果的にメモリの消費を極端におさえることができる。この方法はマルチスレッドで動作させるために最低ふたつのプロセスを起動する必要がある。ひとつはCOMクライアントが起動するプロセスであり、もうひとつはActiveX.EXE（COMサーバー）が起動するプロセスである。しかしCOMクライアントのプロセスは、ActiveX.EXEを起動した直後にシャットダウンするため問題とはならないだろう。
また、ユーザー接続を待機するユーザー接続リクエストブローカとDBアクセスサーバーが同じプロセスで動作することでSocket IDが共有できるようになり、Type4 DB Server以来の問題点だったコールバック方式を廃止することができた。コールバック方式は接続の仕組みが複雑であるうえに、クライアント側はTCP/IPサーバーとなるため、複数のアプリケーションをクライアント側で起動できないという問題点もあった。
Visual BasicでマルチスレッドのTCP/IPサーバーが作れるということは、多くの可能性を生むことに気付くだろう。ここで紹介した方法はトリッキーな方法でもなく、また、COMアーキテクチャにも準拠しているので、十分に勧めることができる。個人的には、この完全なマルチスレッド化がDB Serverの最大の進歩だったと考えている。 1999年4月号「第13回 コンポーネント化されたHyper SQLdb Client Libraryが、プログラミングを簡素化する」から4回にわたり、クライアント側のコンポーネントであるHyper SQLdb Client Libraryを実装している。Hyper SQLdb Client Libraryは、Type9 DB Serverにアクセスするための専用コンポーネントで、プログラミングスタイルにADOとの互換性をもたせるために最大限の努力をしている。使用するユーザーからみれば、DB Serverのためだけに新しいプログラミングスタイルを覚えなければならないことは大きなコストとなる。この点を考えると、ADOのプログラミングスタイルを踏襲できることには意味がある。
1999年8月号「第17回 Access 2000はType x DB Serverのクライアント開発ツールになりえるか？」以降では、クライアントにMicrosoft Access 2000を使用するための調査を行なった。かなりの苦労をした結果、玉砕したことは記憶に新しい。「Access 2000はMicrosoft SQL Server 7.0（とJetデータベースエンジン）にアクセスするアプリケーションを開発するのには優れたツールだが、その強力なユーザーインターフェイス開発機能をほかのデータベースエンジンのために使用することは難しい」。これが、苦労の末に私が得た結論である。
この連載の打診が最初にあったとき、その内容は「Microsoft Accessによるクライアントアプリケーションの開発」という内容だった。「それだったら、サーバーも作りましょう」と提案したのは私自身である。当時のMicrosoft Accessのアーキテクチャは、クライアント／サーバーシステム開発ツールとしては致命的な問題点があり、それはサーバーを自作したところで回避できるものではなかった。しかし、連載を続けてゆくうちに事態はかわるかもしれないと考えていた。実際、Access 2000はSQL Server 7.0用の開発ツールとして強化された。私はほかのデータベースサーバーに対しても十分に使えると判断したし、そう判断するだけの十分な理由があった。このあたりは記事にも詳しく書いた。しかし……。
