SQL サーバーは、スタンダード SQL のさまざまな部分を実装しているので、移植可能なデータベースアプリケーションの作成が可能となります。非常に単純な SELECT や INSERT は容易ですが、必要なことが増えれば増えるほど、作成が難しくなります。多数のデータベースを使用しながら素早い速度が要求されるアプリケーションの場合は、さらに難度が上がります。
どのデータベースシステムにも欠点はあります。それはつまり、データベースのすべてに何らかの弱点があります。言い換えると、動作の相違を招くさまざまな設計上の障害があります。
複雑なアプリケーションを移植可能にするには、ともに稼働する必要のある SQL サーバーを選択し、それらのサーバーがサポートする機能について決定する必要があります。MySQL crash-me プログラムを使用すると、データベースサーバーの選択に使用できる関数、型、制限を調べることができます。crash-me は存在するすべての機能を確認するわけではありませんが、約 450 項目のテストを幅広く行うため、ほぼ包括的といえます。たとえば、crash-me が提供する情報の例として、Infomix や DB2 の使用を可能にするには、18 文字を超えるカラム名は使用できません、といったものがあります。
MySQL ベンチマークと
crash-me
プログラムはいずれもデータベースへの依存度が非常に低くなっています。これらのプログラムがどのように処理されているかを調べることによって、データベースに依存しないアプリケーションを作成する際に必要なことに関する感覚を得ることができます。プログラム自体は、MySQL
ソース配布の
sql-bench
ディレクトリにあります。これらは Perl
で書かれ、DBI
データベースインタフェースを使用する。DBI
の使用それ自体で移植性の問題の 1
部分を解決できます。これはデータベースから独立したアクセス方法をとるからです。項4.1.4. 「MySQL ベンチマークスィート」
を参照してください。
データベースの独立性の獲得を目指す場合は、SQL
サーバーそれぞれのボトルネックを正しく理解する必要があります。たとえば、MySQL
では、非常に高速に
MyISAM
テーブルの行の取り出しと更新が行われますが、同じテーブル上に低速のリーダーとライターが混在する問題があります。一般にトランザクションデータベースの場合、ログテーブルからのサマリテーブルの生成時は行ロックがほとんど役に立たず、問題が生じやすくなっています。
アプリケーションを実際にデータベース非依存にするには、データ操作に使用する簡単な拡張可能インタフェースを定義する必要があります。たとえば、ほとんどのシステムでは C++ が使用できるため、データベースに C++ クラスベースのインタフェースを使用することは道理にかなっています。
あるデータベースに固有の機能を使用する場合
(MySQL の
REPLACE
コマンドなど) は、ほかの SQL
サーバーでその機能を実装できるようにするメソッドをコード化する必要があります
(ただし低速化します)。低速化しますが、ほかのサーバーで同じ作業を実行できるようにします。
MySQL
を使用すると、/*!*/
構文を使用して MySQL
固有のキーワードをクエリーに追加できます。/*
*/
内のコードは、その他の SQL
サーバーのほとんどでコメントとして処理
(無視)
されます。コメントの挿入に関する情報は、項5.5. 「コメント構文」を参照してください。
一部の Web アプリケーションのように正確性よりパフォーマンスが重視される場合は、すべての結果をキャッシュするアプリケーションレイヤを作成すると、さらにパフォーマンスを改善できます。一定の期間後に古い結果を '期限切れ' することで、キャッシュを適度に最新の状態に保持できます。これにより、キャッシュを動的に拡大し、通常の状況に戻るまでタイムアウト期限を高速に設定して、高負荷のスパイクを処理するメソッドが提供されます。
この場合、テーブル作成情報にキャッシュの初期サイズと通常時にテーブルがリフレッシュされる頻度に関する情報が組み込まれます。
アプリケーションを実行する代わりに MySQL クエリーのキャッシュを使用するのは、効果的です。クエリキャッシュを有効にすることで、クエリー結果が再利用できるかどうかの判断の詳細をサーバーに一任します。これによりユーザーのアプリケーションは単純化します。項4.5.5. 「MySQL クエリキャッシュ」 を参照してください。