2つの関連技術のコンテキストで「ネイティブ」とはどういう意味ですか？

Question

問題のシナリオは、非常に悪意のある Microsoft Jetデータベースエンジンに関連しています。アサーションは、データアクセスオブジェクト（DAO）データアクセステクノロジーがJetに「ネイティブ」であるというものでした。 、DAOモデルを介してオブジェクトを作成することは、 Microsoft Access ユーザーインターフェイス。

さらに、DAOを介して何かを作成できなかった場合、定義上、Jetに「ネイティブ」ではないと断言されました。

私にとって、この「ネイティブ」の定義は間違っているようです。歴史的およびマイクロソフトの政治的理由により、DAOから省略または部分的にのみ実装された多数のJetオブジェクトがあります（ CHECK 制約、固定幅データ型、 DECIMAL データ型、圧縮可能なデータ型など）が、JetのSQL データ定義言語に含まれていました（ DDL）。直感だけで、Jet SQL DDLはJetエンジンの「ネイティブ」と見なされるべきであることがわかります。

だから私の質問は次のとおりです。なぜ外見上（DAO）の技術は「ネイティブ」と見なされ、別の内見の技術（SQL DDL）は「非ネイティブ」と見なされるのですか？何かが「ネイティブ」かそうでないかを気にする必要がありますか？

Answer 1

たぶんここは間違っているかもしれませんが、私はいつも次のように理解していました：

• MS Jetデータベースエンジンは、必ずデータベースエンジン（パワー不足かどうか）です
• それは「ネイティブ」です外部世界へのインターフェースはSQLの方言です

whereas：

• DAOは、Microsoftのデータベース抽象化レイヤーの1つであり、VBAやWindowsスクリプトなどのCOM環境で使用するように設計されています
• Access（MS JetはMS Accessなしでも存在できるため、MS Jetのユーザーインターフェイス/レポートツールと見なすことができます）で開発され、MS JetとMS Accessの両方に強力にバンドルされています。 ADOが存在するのと同じカテゴリ内

Answer 2

この質問は、私の意見では、誠意を持って投稿されたものではありません。完全に私と、あなたのコメントに応じて作成したコメントに向けられています。すでに他のすべての問題に回答しましたが、わかりやすくするために、Jetの歴史の概要を説明します。

ジェットは、Accessとともに90年代前半に導入されました。バージョン1と2の間で、MSはFoxproを買収し、その「Rushmore」を組み込みました。 Jetへのテクノロジー。この期間のどこかで、MSはJetへのインターフェイスレイヤーとしてDAOを開発しました。すべてのデータアクセスにJetを使用したデータインターフェイスレイヤー以外の存在としてDAOが存在していたという事実は知りませんが、それは私に見えた方法です。 Jetは、ODBCとインストール可能なISAMを使用すると、ネイティブJetデータの外観と動作と同じように、アプリで当時の一般的なデータベース形式のほぼすべてを表示および動作させることができるため、かなり良い選択でした。当時、デスクトップデータベース市場はdBaseとその亜種とParadoxに支配されていました。これらはすべてサーバーデータベースではなく、デスクトップデータベースエンジンでした。サーバーデータベースへのアクセスは一般にODBCを介して行われていましたが、当時はデスクトップデータベースアプリケーション開発者にとってそれほど重要ではありませんでした。 JetはODBCデータソースに接続し、かなり効率的に利用することができましたが、それは時々間違いを犯します（そして、Jetのデータ処理エンジンの特定の側面をバイパスするODBCDirectがJetに導入された理由です）。

現在、Access / Jet / DAOの台頭と並行して、Visual Basicは一般化されたWindowsアプリ開発のホットな製品であり、Webが繁栄する前は、VBは世界で最も広く使用されていたプログラミング言語でした。 DAOとJetはVB開発者にあらゆる種類のデータストアへのインターフェイスを提供し、VB開発ツールはそれらとうまく統合されました。したがって、ODBCの後、DAOはMSの主要なデータインターフェイスレイヤーになり、Jetエンジンを使用してあらゆる種類のデータを処理しました。

当然、これには問題があり、Jet / DAO（およびVB）はすべてデスクトップ指向のツールであるという点でも非常に制限的でした。 90年代半ばから後半までに、MSはデスクトップソフトウェア、デスクトップOS、および開発ツールのプロバイダーからエンタープライズソフトウェアプロバイダーへの拡大を試みていました。そのため、MSは、データベースサーバー用のODBCのような、より堅牢なデータインターフェイスを開発する必要がありましたが、新しいサーバーデータベースが提供する最新の機能をすべて備えています。 OLEDBは、OLEDB上のインターフェイス層としてADOを使用した場合のこれに対する答えでした（DAOがJet上のインターフェイス層であるように）。 DAOの目標はJetデータベースエンジンを介して多くのデータストアへのアクセスを提供することでしたが、OLEDBはODBC、データベース抽象化レイヤーなどのより中立的なデータインターフェイスレイヤーであり、ADOはその中立的なデータインターフェイスレイヤーへのインターフェイスでした。

「ネイティブ」の質問についてDDL、Jet 4以前はSQL DDLのサポートが非常に貧弱だったという事実です。つまり、SQL DDLを介して制御できないJetの機能がありました。代わりに、これらの機能を制御するにはDAOを使用する必要がありました。 Jet Database Engine Programmer'sにはDAOの例に加えてDDLの例が含まれていますが、Jet DDL SQLはJetデータベースのすべての機能をサポートしていないため、DAOの例ではさらに多くのことができます。

非常に混乱していると思われる内訳は、MSの内部政治のために生じました。 1999年までにMSがAccess 2000（Jet 4.0の新バージョン）を導入したとき、MSはADOを支持してDAOを廃止したいと考えていました。 MSは、ADOを使用する意味がない場合（つまり、データストアがJet）でも、ADOをAccessの既定のデータインターフェイスレイヤーにしました。この取り組みの一環として、MSはJet 4のすべての新機能のサポートを組み込むためにDAOを完全には更新しませんでした。代わりに、彼らはこの取り組みをADOに注ぎ込みました。その結果、JetのネイティブデータインターフェイスレイヤーであるDAOには、データベースニュートラルインターフェイスが必要とするJet機能のサポートが欠けていました。