歴史的/進化的および市場の力の理由の組み合わせです
数年前にMicrosoftで働いていたとき、開発中のいくつかの異なるデータ製品があることは明らかでした。各オファリングは、特定の市場またはユースケースを対象としています。例:
Accessは、フォームとレポートを使用してアプリケーションを構築できるカードインデックスシステムに慣れているデスクトップユーザーを対象としています。SQLは自然な追加でした。これはすべて、「JET」という名前の独自のローカルマシンデータベースエンジンを使用しました。最終的にJETは中止されました-ブドウのつるについての言葉は、(信頼できる)ソース管理の欠如がソースの大部分を失ったことを意味したということでした。
FoxProは、リレーショナルデータよりも高速なデスクトップユーザーを対象としています。
SQL Serverは、企業が必要とするすべてのスケール/電力/可用性などを備えたエンタープライズ/サーバー側の「ビッグ」データベースシステムでした。IIRC、MSは、MSSQLを構築するSybase 6のバージョンをライセンスしました。
時間が経つにつれて、境界の一部がぼやけてきました。たとえば、SQL Serverは現在デスクトップマシンで実行できますが、ユースケースは残っています。
これにより、3つの「バックエンド」、つまりMicrosoftが作成したデータベース製品が得られます。
ミックスに追加するために、これらのシステムにアクセスするためのさまざまなレベルの開発者APIが提供されました。
最初は、APIの方法はあまりありませんでした-アプリケーション(FoxPro / Access)内にコードを記述しました。VBAは1つの方法でした。
MicrosoftはWindowsがOracle、Sybaseなどの大きなデータベースと通信できるように、競合するシステムに接続するためにMS ODBCを実装しました。ExcelはODBCツールを取得する注目すべきアプリの1つです。 / graphsなど。多くのデータベースベンダーは、異なるクライアントが接続できるようにODBCを実装することになりました。そのため、この戦略はある程度成功しました。ODBCは、最小公分母を表すと見なすことができます。
さまざまなチームが、ローカルのDAO(データアクセスオブジェクト)やリモートのRDO(リモートデータオブジェクト)などのデータベースエンジンにアクセスする独自の方法を作り始めました。これは当時最も人気のあるMS開発者製品でした。
これらの多様なAPIを合理化し、単一/統一された非常に柔軟なデータベースアクセスAPIを提供するための内部努力により、OLEDBが得られましたが、それを取得するのは非常に困難でした(多くのC ++テンプレート)。
OLEDBはVBから使用できなかったため、ADOはActiveX技術を使用して開発されたため、COM、OLE、ActiveXを実行できるもの、つまりAccess、Excel、VB、したがってASPがデータベース対応になり、再利用可能になりました。
.NET時代に移行すると、ADOはさまざまなメリットをもたらす.NET環境に自然に移行しました。
LINQの登場により、実際のデータベースアクセスメカニズムの問題は少なくなりました。
警告-私は少し前に去ったので、私の記憶は少し曖昧です