2 目標と考え方

2.1     SQL レベルの API

多くのアプリケーション開発ツールで、この API を使用したコードが生成されるようになることを期待します。また、現在 Java で利用できる呼び出しレベルの SQL インタフェースは他にないので、プログラマにとっても有用な API となることを目指しています。

2.2     SQL の互換性

• JDBC では、どんなクエリー文字列でも背後の DBMS ドライバに渡すことができます。そのため、DBMS のどれかからエラーが返される可能性を覚悟すれば、アプリケーションは使いたい SQL 機能をどれでも使用できます。実際には、アプリケーションのクエリーは必ずしも SQL でなくてもよく、特定の DBMS 用に設計された特別な SQL 構文 (たとえばドキュメントや画像のクエリーなど) でもかまいません。
  
  
• JDBC 準拠テストに適合して JDBC COMPLIANT(TM) と呼ばれるためには、ドライバは ANSI SQL92 Entry Level 以上をサポートする必要があります。このレベルのサポートにより、幅広い移植性が必要となるアプリケーション間で最低限の共通基準が保証されます。ANSI SQL-2 Entry Level は能力的に適当で、幅広くサポートされているので共通基準として適切であると考えられます。
  
  

2.3     通常のデータベースインタフェースの上に実装可能であること

2.4     Java システム全体の一貫性を維持する Java インタフェースの提供

既存の Java のコアクラスのスタイルと長所をできる限り尊重した Java データベースを提供するよう努力します。

2.5     単純に

2.6     可能な場合はいつでも強力で静的な型チェックを使用

SQL では本質的に動的に型付けが行われるので、実行時に型のミスマッチエラーが発生することがあります。たとえば、SELECT からの戻り値として整数を期待してプログラムが記述されているのに、データベースから文字列 foo が返されるような場合です。しかし、プログラマが期待する型をコンパイル時に表現できるべきだと考えるので、この API ではできる限り静的に型チェックを行います。また必要に応じて、動的に型付けされるインタフェースもサポートします (詳細については、第 14 章を参照)。

2.7     よくあるケースは単純に

よくあるケースとは、単純な SQL 文 (SELECT、INSERT、UPDATE、DELETE など) をパラメータなしで実行し、次に (SELECT 文の場合) 単純な型の結果行を処理するような場合です。IN パラメータを持つ SQL 文もよくあるケースです。

それほど頻繁ではないが重要なケースに、INOUT パラメータか OUT パラメータを使って SQL 文を呼び出す場合があります。また、数メガバイトのオブジェクトの読み書きを行う SQL 文もサポートする必要があります。さらに、あまり頻繁ではないケースとして、複数の結果セットが SQL 文から返されるケースもサポートする必要があります。

メタデータアクセス (結果型セットの検索やデータベース内のプロシージャの列挙など) は比較的まれで、高度なプログラマやビルダツールにより使用されると考えられます。そのため、メタデータ関数については、動的に型付けされたデータアクセスとともに、仕様の最後で説明します。標準的なプログラマはこれらの説明を読み飛ばしてもかまいません。

2.8     複数の機能は複数のメソッドで表現

一般に、Java のコアクラスの考え方は、異なる機能を表現するには異なるメソッドを使用するというものです。その結果メソッドの数は多くなりがちですが、個々のメソッドは理解しやすくなります。この方法には、プログラマが基本的なインタフェースの使用方法を学ぶときに、複雑な動作に関係する引数を指定する必要がないので、混乱を避けられるという長所があります。

JDBC インタフェースにもこの方法の採用を試みました。全般に、フラグ引数付きの多目的メソッドよりも、複数のメソッドを使用するようにしました。