データベースが言語機能として統合されないのはなぜですか？

外部SQL（または他の）データベースに接続するのではなく、一流の言語機能として組み込みデータベースを備えたプログラミング言語はありますか？そのような機能の欠点と利点は何ですか？そのような機能はどのように見え、プログラムの方法をどのように変えるでしょうか？

私が考えることができる唯一の言語は、DBase、Clipper、FoxProなどの古いxBase言語です。Clipと呼ばれる無料でほとんど互換性のあるバージョンを提供するGNUプロジェクトがあります

プログラミング言語をデータベースプラットフォームに直接結び付けたPick Basicもありました。

これは行われました。言語がデータにアクセスする方法を制限したのは、進化の行き止まりでした。

言語は「小」であり、データベースは「大」です。そのため、2つを組み合わせると、データベースは機能としての言語ではなく、言語は機能としてのデータベースになります。多くのデータベースには、PL / SQL、T-SQLなどの独自の言語がいくつか付けられています。

私は必ずしも正しい質問が「なぜそこにないのか」だとは思わない。しかし、「なぜあるべきですか？」。データベースを言語の機能にすることで何が得られるでしょうか？言語はプログラミングスタックの最下部にあることを忘れないでください。言語を肥大化させることはすべてに影響します。したがって、言語設計者は新しい機能、特にそのような投資を伴う機能の追加に時間がかかる必要があります。

要件に近い3つのレガシーシステムがあります。

1. 選んで、
2. MUMPS、
3. Microsoft Access

PickおよびMUMPSは、リレーショナルデータベースに関する最初の学術論文の数年前に開発されました（これは、最初の商用SQLベースのデータベースシステムが市場に登場する約10年前でした。成功したSQLベースのシステムは後でありました）。それらはまだ使用されていることがあります（最近の旅行計画システムではPickを使用して、地元の公共交通システムを使用していました）。PickやMUMPSとは何の関係もありません。私ができる最善のアドバイスは、「空中に手を置いてキーボードから離れてください」ということです。それらに何か関係がある場合は、「ごめんなさい」というフレーズが耳に鳴っているはずです。

Microsoft Accessは、IT開発者にとって重要なビジネスアプリをAccessから簡単に作成し、文字通り会社なしでは生きられないものに変化させることが容易であるため、IT界でひどくand笑され批判されています。また、かなりの数の開発者がMS Accessを介した開発に着手し、物事が行き詰まるにつれて、それらを修正する方法を学びました（最初のステップは、VBで最初にVisual Basicを学習し、次にAccessアプリを書き直すことです「より良い」何かで）。大量のデータを分散して実行する適切に動作するAccessアプリを作成することは可能です-私はそれを見てきました-しかし、物事を行う簡単な方法があり、井戸を作る（そして維持する）ためにはるかに少ないスキルが必要ですVBおよびSQL Serverから動作するアプリ。

SQL Server 2005以来、MicrosoftはCLRをストアドプロシージャと関数に入れる機能を導入しました。そして、それについてトリッキーにしたい場合は、データベースの列として使用できるデータ型を作成できます。OracleはJavaと似たようなものを持っていると思います。

そうは言っても、それを作成したり、それらについて仮説を立てたりすることを妨げるものはないと思います。ここでは、PickとMUMPSはほとんどのコーダーよりも古く、非常にCOBOL的な世界観を反映しています。

私の個人的なアドバイスは、物事を分離することです。プロジェクトに必要なデータの操作に優れた言語を使用します（「最高の」言語は、コードを読み書きできるプログラマを簡単に見つけることができる場合があることに注意してください）。プロジェクトに必要なデータの保持に優れたデータベースシステムを使用します。

プログラミング言語にデータベースを追加すると、非常に狭い範囲のユーザーにしか対応できない場合があります。RDBMS以外の機能を使用する場合はどうなりますか？または、データベースをまったく使用したくないですか？このようなユースケースでは、コンパイラは不必要に肥大化します。

エラー

まあ、最初に、言語が動作するフレームワークがデータベースを提供しない理由を尋ねています。言語は、単に設定した文法でやりたいことを表現する手段です。実際にはそのようなサービスは提供していません。:)

とはいえ、いくつかの理由があります。

• 効率的なデータベースストレージシステムの構築は難しい問題であり、おそらく.NET Frameworkの構築と同等かそれ以上です（たとえば）。チームがデータベースをフレームワークに含めようとした場合、それだけで作業を完了します。

• 負荷を取得するデータベースは、アクセスするコードのプロセスではなく、独自のマシン上にある必要があります。

• ORMは、フレームワークを実際にデータベースにしようとせずに、このようなアクションの利点となる多くのタイプセーフティとコンパイル時チェックを提供します。

そうは言っても、データアクセスの必要性が小さいアプリケーションが操作できるフレームワーク内に何らかのSQLite実装を含めるのは適切だと思います。ただし、それが重要なアプリケーションで役立つかどうかはわかりません。

彼らです; そのような言語は4GLと呼ばれます。DataFlexは私のお気に入りですが、もう使用しません。

警告：DataFlex v3.0のオブジェクト指向バージョンの開発を支援しました

あなたの実際の質問は、「データベースライブラリに付属するプログラミング言語がないのはなぜか」だと思います。

汎用言語は、ディスク、ウェブカメラ、ネットワーク、画面、メモリ内の場所への書き込みまたは読み取りから、すべてのIOを同じものとして扱います。すべてIOであり、プログラミング言語が関係するのはそれだけですと。

実際、ヒープおよびスタックへの読み取り/書き込みを除いて、ほとんどのプログラミング言語は実際のIOも実行しません。一部の言語はIO操作を表現するためのネイティブ機能（BASIC のprint コマンドなど）を提供しますが、ほとんどの言語はそれらを通常の関数呼び出し（printfCなど）として扱い、ライブラリに実際の書き込みを処理させます。

C＃などの一部の言語は、クエリを表現するための言語機能を提供しますが、それでも、それらはライブラリのSQL操作に変換されるリスト（またはIEnumerable。言語自体はまだIOの非常に抽象的な概念で動作しています。

プログラミング言語の標準ライブラリにデータベースパッケージを構築するのは良い考えではない理由については、標準ライブラリの他にデータベース機能に通常依存するものはないためです。

はい。AS / 400プラットフォームの言語は、データベースのネイティブなファーストクラスサポートを備えています。

これは、AS / 400プラットフォームのすべての場所にデータベースが完全に統合されており、結果セットのナビゲーションが容易で、途中で値を更新できるなど、非常に優れた機能が多数あるためです。

言語とプラットフォームに依存します。たとえば、Cで作業しているときにさまざまなデータベースを使用するのは非常に簡単で、適切なライブラリを使用するだけです。

言語は標準実装を維持する必要があります。これは通常、誰かが構築したいものを構築できるようにするために必要な最小限の量を提供することを意味します。それ以外はすべてライブラリになり、他の人が管理している言語の拡張になります。

少なくとも、これはISOなどの組織によって確立された標準に従う言語の場合です。

上記の反例が示しているように、書かれているように、質問は部分的に間違っています。

そこで、まず、なぜ汎用の高レベルプログラミング言語の機能としてDBMSが統合されていないのか、という質問をまず読み上げます。

これは、オペレーティングシステム、ファイルシステム、Webサーバー、キャッシングレイヤーなどの他のソフトウェア製品が通常は組み込まれていないのと同じ理由です。汎用言語は一般に、そのような製品の抽象化レベルを超える抽象化レベルで動作します。DBMS実装するプログラマのための合理的だ、それはそうでは汎用言語であり、そのDBMSは親言語の側面や、DBプログラマーが使用するDB固有の宣言型言語を公開することさえあります。しかし、DBMSの作成には設計オプションが多すぎて、汎用プログラミング言語で修正するのが賢明ではありません。それらを修正すると、MUMPSのようなケースになります。この2つの絡み合いにより、業界全体が鶏と卵の問題に陥り、廃止されたDBMSと廃止されたプログラミング言語に固執します。

NonStop / C、NonStop / C ++、NonStop / Cobol、NonStop / Fortran、およびおそらく他の言語に完全に統合されたNonStop / SQLで動作するために使用され、コンピューターが稼働するオペレーティングシステムであるNonStop / Guardianと完全に統合されました走った

データベースがオペレーティングシステムのファイルシステムである場合、おそらく、これが最も近い統合だと思います。また、行き止まりであり、コンポーネント、データベース、オペレーティングシステム、ハードウェア、およびそこに記述されたソフトウェアを個別に分離して別の環境に移植することはできません。

PCに最も近いのはMS Accessで、Embarcadero / Borland Delphiが2番目に近いでしょう。

その後、アプリケーションに埋め込まれたデータベースを確認します。これは、単純な構成ファイルに簡単に保存できない階層データのセットを必要とする、および/またはアプリケーションの実行時に定期的な更新を必要とするスタンドアロンアプリケーションを作成する人に限定された魅力を持つことができます。または、より大きなデータベースの一部のスナップショットを保持し、アプリケーションが接続できるときに大規模なデータベースとスナップショットを同期するポータブルバージョンのアプリケーションが必要な場合（たとえば、手の届かないところにいるセールスマンなど）企業ネットワークにはまだ顧客グループの販売データ、または患者の記録を必要としているが、行くべきネットワークアクセスがないため病院のネットワークに接続できない現場の医師が必要です。

元Visual Foxpro開発者として、リレーショナルモデルを言語の一部として定義している主流の言語が存在しないことは奇妙です。

完全なデータベースエンジンを使用することはお勧めできませんが、代わりに「SQL」言語を使用することは非常に便利です。

オブジェクト指向では、インピーダンス不整合が存在します。これは、オブジェクトとセットが互いに似ていないために発生しました。しかし、言語でTABLES、FIELDS、RELATIONS、CONSTRAINSなどを（特定のストレージに結び付けずに）定義すると、非常に強力になります。さらに、ORMを作成すると、さらに1対1のマッピングになります。