次の方法で共有


標準のプログラミング インターフェイス

プログラミング インターフェイスは、おそらく標準化の最も明白な候補です。 実際、ODBC の開発時には、ANSI と ISO によって埋め込み SQL モジュールと SQL モジュールの標準が既に提供されていました。 データベース CLI の標準は存在しませんが、SQL Access Group (データベース ベンダーの業界コンソーシアム) は、データベース CLI を作成するかどうかを検討していました。その後、ODBC の一部が作業の基礎となりました。

ODBC の要件の 1 つは、1 つのアプリケーション バイナリが複数の DBMS で動作する必要があるということです。 このため、ODBC では埋め込み SQL またはモジュール言語が使用されません。 埋め込み SQL 言語とモジュール言語の言語は標準化されていますが、それぞれが DBMS 固有のプリコンパイラーに関連付けられています。 したがって、アプリケーションは DBMS ごとに再コンパイルする必要があり、結果のバイナリは 1 つの DBMS でのみ機能します。 これは、ミニコンピューターとメインフレームの世界で見つかった少量のアプリケーションでは許容されますが、パーソナル コンピューターの世界では受け入れられません。 第一に、大量のシュリンクラップされたソフトウェアの複数のバージョンを顧客に提供することは、物流上の悪夢です。2 つ目は、多くの場合、パーソナル コンピューター アプリケーションが複数の DBMS に同時にアクセスする必要がある場合です。

一方、呼び出しレベルのインターフェイスは、各ローカル コンピューターに存在するライブラリまたはデータベース ドライバーを使用して実装できます。DBMS ごとに異なるドライバーが必要です。 最新のオペレーティング システムはランタイムにこのようなライブラリ(Microsoft Windows オペレーティング システム上のダイナミック リンク ライブラリなど)を読み込めるため、1 つのアプリケーションが再コンパイルせずに異なる DBMS のデータにアクセスでき、複数のデータベースのデータを同時にアクセスすることもできます。 新しいデータベース ドライバーが使用可能になると、ユーザーはデータベース アプリケーションを変更、再コンパイル、または再リンクすることなく、コンピューターにこれらをインストールできます。 さらに、呼び出しレベルのインターフェイスは ODBC の候補として適していました。これは、ODBC が最初に開発されたプラットフォームである Windows が既にこのようなライブラリを幅広く使用しているためです。