データベースアプリケーション開発のターゲット環境として、OracleやSQL Serverなどの「本格」RDBMSは、金融機関のオンラインシステムなど、同時に多数のユーザが接続して、多数のトランザクションを発生させるようなシステムでの性能を競ってきました。

しかし、DBISAMは、もともとシングルユーザのデスクトップ・データベース環境と、ファイル共有型の複数ユーザ環境をサポートするように設計され、最近になってようやくクライアント・サーバ型のモデルをサポートした製品です。

Oracleや MS Access には、それぞれの得意分野があり、DBISAMは決してそれらの製品を完全に置き換えるべき製品ではありません（BDEによるParadox/Dbaseアクセスにはほとんどの点で勝っているので、置き換えて後悔はないでしょう）。以下に、DBISAMが他の製品と違う点を挙げて、その強みと弱みを解説します

DBISAMは小じんまりした環境をターゲットにしています

DBISAMが特に適していると思われるシステム用途は以下の通りです

• シングルユーザのデスクトップアプリケーション
• 複雑なトランザクションや同時実行トランザクション数の少ないLAN上のデータベースアプリケーション
• 上記のアプリケーションを、WAN/インターネット越しに地理的に広げたデータベースアプリケーション

これらの用途のために、OracleやSQLサーバなどの本格RDBMSを使うのはオーバースペックです。DBISAMのコストパフォーマンスが遺憾なく発揮されるでしょう。

ほとんどのクライアント・サーバ型RDBMSのネットワークプロトコルはLAN環境向けに設計されているため、WAN/インターネット環境では使い物になりませんが、DBISAM C/Sはインターネット向けに最適化されたプロトコルを持っていることも特筆すべきことです。

DBISAMはVARCHAR型をサポートしません。

DBISAMは、メモ型、Blob型のフィールド以外のデータについて、固定長のレコードからなるデータファイルを構成します。可変長文字列、いわゆるVARCHAR型はサポートせず、文字列はすべて固定長文字列フィールドに保持します。そのため、大きなサイズの文字列フィールドを多数持つ場合に、データファイルが大きくなりやすいという性質を持っています。

固定長文字列フィールドの最大長が250である点にも注意が必要です。これを越えるフィールドはMemo型となり、インデックスの作成対象にできなくなります。固定長レコードのアーキテクチャを捨て、可変長レコードをサポートする予定は、今のところVer.3.xでは予定されていません。もっとも、250文字を越える文字列フィールドに対して検索を多用するようなアプリケーション設計は、DBISAMでは許されません。

DBISAMは同時に多数のトランザクションを扱うのが苦手です

もともと、ファイル共有型のDBMSアーキテクチャは同時に多数のトランザクションが競合した場合の処理に困難があります。DBISAMのトランザクションの実装は、事実上トランザクションをシリアライズ（順番に一つづつ実行）することによって、複数セッション間でのデータの整合性と安全性を確保しています。

このことは、ファイル共有型DBMSとしては最善といえるのですが、クライアント/サーバ型の本格的なデータベースに比べると、多数のトランザクションが同時に実行されるケースでのパフォーマンスが著しく劣ることは否定できません。なお、ユーザが多数でも、データ更新を伴わない参照のみのアクセスであれば問題ありません。

DBISAMは、インデックスの効かない検索が苦手です

MS Access や Paradox は、エンドユーザがクエリビルダなどを使って様々なクエリを自分で作って実行する機能を「売り」にしていますが、DBISAMは、エンドユーザによるクエリ作成を想定せず、開発者がクエリを作成し、テーブルを設計することを前提にしています。

このために、クエリ最適化アルゴリズムが大きく異なっています。BDEやAccessのクエリオプティマイザは、インデックスが効かないフィールドでの検索を行う際に、テーブル上のデータを貪欲にメモリに先読みして、力づくでデータをスキャンして検索をする性質を持っていますが、DBISAMは、検索の際には有効なインデックスがあるものとの前提に立って、インデックスを最大限活用した検索を行います。

このため、DBISAMでは、有効なインデックスが定義されている場合には、少ないメモリ消費とディスクI/Oで、高速に検索が可能ですが、有効なインデックスが存在しない場合には、著しく性能が悪化します。（AccessやBDEに負けます）

DBISAMの開発チームの優先順位は、今も変わっていないので、「力づく」の検索向けの最適化がすぐに実装される見込みはありません。システムのデータベースアクセスのパターンを予め明らかにした上で、チューニングを施せば、素直に応えてくれるDBMSなので、その点は玄人向けといえるのかもしれません。目に見える効果が出るのでDBチューニングを学ぶのにも適していると思います。

DBISAMはアプリケーションにビルトインして使うためのSQLエンジンで、コンパクトでシンプルで安価であるところに意義を見出しています。OracleやAccessと完全に同列に比較するのは、かえって不公平というものでしょう。

DBISAMはデータの安全性を重視しています

データの安全性という点で見た場合、BDEのデフォルトの設定はかなり危険なものだといわざるを得ません。BDEは更新をメモリにキャッシュし、ディスク書き出しのタイミングをプログラムからコントロールできないため、予期せぬソフトウェアの強制終了が発生した場合に、データが失われてしまう可能性が極めて高いのです。

DBISAMは、トランザクションをコミットするタイミングでデータを書き込みますが、その最中に電源障害などが起こらない限り、データの整合性が保たれます。特にDBISAM C/Sでは、トランザクションのコミット中にサーバが異常終了しない限り、データは安全です。

DBISAMは、こまめにデータを書き込むため、更新パターンによっては遅く感じられることもあるかも知れません。Delphiが提供するTDataSetProviderとTClientDataSetを使って、更新をローカルにキャッシュし、まとめてトランザクションを使って更新するなど、工夫次第でパフォーマンスを向上させて利用してください。チューニングの方法はいくつもあります。

△[前] ▼[続き]