データベースが言語機能として統合されていないのはなぜですか？
外部SQL（または他の）データベースに接続するのではなく、ファーストクラスの言語機能として組み込みデータベースを備えているプログラミング言語はありますか？そのような機能の欠点と利点は何でしょうか？そのような機能はどのように見え、プログラムの方法をどのように変更しますか？
私が考えることができる唯一の言語は、DBase、Clipper、FoxProのような古いxBase言語です。 GNUプロジェクトがあり、 Clip と呼ばれる無料でほとんど互換性のあるバージョンを提供しています==
これも Pick Basic で、プログラミング言語をデータベースプラットフォームに直接結び付けました。
これは行われました。言語がデータにアクセスする方法を制限するのは、進化の行き止まりでした。
言語は「小さい」、データベースは「大きい」。したがって、2つを組み合わせると、データベースとして機能を持つ言語ではなく、言語として機能を持つデータベースになります。多くのデータベースには、独自の言語が追加されています。 PL/SQL、T-SQL。
私は必ずしも正しい質問が「なぜそこにないのか」とは思いません。しかし、「なぜあるべきなのか？」。データベースを言語の特徴とすることから何が得られますか？言語はプログラミングスタックの最下部にあることに注意してください。言語を肥大化すると、すべてに影響します。したがって、言語設計者は、新しい機能、特にそのような投資を伴う機能を追加するのに時間がかかる必要があります。
要件に近いレガシーシステムが3つあります。
- ピック 、
- [〜＃〜]おたふく風邪[〜＃〜] 、
- Microsoft Access
PickとMUMPSは、リレーショナルデータベースに関する最初の学術論文（これは最初の商用SQLベースのデータベースシステムが市場に登場するまでの約10年前）から数年前に開発されました。成功したSQLベースのシステムは後でされました）。あなたはそれらがまだ使用されているのを見つけるかもしれません（私たちの地元の公共交通機関システムは最近まで旅行計画システムにPickを使用していました）。 PickやMUMPSとは何の関係もありたくないので、私ができる最善のアドバイスは、「手を離してキーボードから離れる」ことです。あなたがdoと何か関係がある場合は、「ごめんなさい」というフレーズが耳に聞こえるはずです。
Microsoft Accessは、開発者以外の人がAccessから重要なビジネスアプリを作成し、文字通りそれなしでは生きていけないものに変化させるのが非常に簡単であるため、ITサークルでひどくあざけられたり批判されたりします。また、かなりの数の開発者がMS Accessを介して開発を開始し、物事が行き詰まり続けるにつれて、それらを修正する方法を学びました（最初のステップは、伝統的にVisual Basicを学び、最初にVBでAccessアプリを書き直すことです。何か「より良い」）。大量のデータが分散されて実行される、適切に動作するAccessアプリを作成することは可能です-私はそれが完了したことを確認しました-物事を行うためのより簡単な方法があり、ウェルを作成（および維持）するためのスキルははるかに少なくて済みますVBおよびSQL Serverから動作したアプリ。
SQL Server 2005以降、MicrosoftはCLRをストアドプロシージャおよび関数に組み込む機能を導入しています。そして、それについてトリッキーなことをしたい場合は、データベースの列として使用できるデータ型を作成できます。 OracleはJavaと似たようなものを持っていると思います。
そうは言っても、あなたがそれを作成したり、それらについて仮説を立てたりすることを妨げるものはないと思います。 PickとMUMPSは、ここにあるほとんどのコーダーよりも古く、世界を非常にCOBOL的に見る方法を反映しています。
私の個人的なアドバイスは、物事を分離しておくことです。プロジェクトに必要なデータの操作に優れた言語を使用します（「最良の」言語は、コードを読み書きできるプログラマーを簡単に見つけられる言語である場合があることに注意してください）。プロジェクトに必要なデータを保持するのに優れたデータベースシステムを使用してください。
プログラミング言語にデータベースを追加することは、非常に限られたユーザーにのみ対応する場合があります。 RDBMS以外の機能を使用したい場合はどうなりますか？または、データベースをまったく使用したくないですか？このような使用例では、コンパイラが不必要に肥大化します。
エラー。
さて、まず、言語が動作するフレームワークがデータベースを提供しない理由を尋ねます。言語は、単にセットグラマーでやりたいことを表現する手段です。そのようなサービスは実際には提供していません。 :)
とはいえ、いくつかの理由があります。
効率的なデータベースストレージシステムを構築することは、おそらく.NET Framework（たとえば）を構築するよりもまたはそれ以上程度の難しい問題です。チームがデータベースをフレームワークに含めようとした場合、それだけで作業を終えることになります。
負荷がかかるデータベースは、独自の別のマシン上にある必要があり、それにアクセスしているコードのプロセス中ではありません。
ORMは、実際にフレームワークをデータベースにしようとせずに、そのようなアクションの利点である多くのタイプセーフとコンパイル時のチェックを提供します。
とは言っても、データアクセスの必要性が少ないアプリケーションが動作する可能性があるフレームワーク内に、ある種のSQLite実装を含めるのは素晴らしいことだと思います。しかし、それが重要なアプリケーションで役立つかどうかはわかりません。
あなたの実際の質問は、「データベースライブラリに付属しているプログラミング言語がないのはなぜですか」だと思います。
汎用言語は、すべてのIOを、ディスク、Webカメラ、ネットワーク、画面、メモリ内の場所への書き込みまたは読み取りであっても、すべてIOです） 、そしてそれがプログラミング言語が関係するすべてです。
実際、ヒープとスタックへの読み取り/書き込みを除いて、ほとんどのプログラミング言語は実際のIOも実行しません。一部の言語では、expressingIO operations（eg printcommand BASICの場合）、ほとんどの言語はそれらを通常の関数呼び出し（Cのprintfなど）として扱い、ライブラリに実際の書き込みを処理させます。
C＃のような一部の言語は、クエリを表現するための言語機能を提供しますが、それでもlists（またはIEnumerables、それらは.NETで呼び出されるため、ライブラリによってSQL操作に変換されます。言語自体は、IOの非常に抽象的な概念で動作しています。
なぜデータベースパッケージをプログラミング言語の標準ライブラリに組み込むのが良い考えではないのかについては、標準ライブラリの他のものがデータベースの機能に通常依存しないためであると考えられます。
はい。 AS/400プラットフォームの言語は、ネイティブのファーストクラスのデータベースサポートを備えています。
これは、AS/400プラットフォームがあらゆる場所に完全に統合されたデータベースを持ち、途中で値を更新する結果セットをナビゲートしやすいなど、非常に多くの非常に優れた機能を可能にするためです。
言語とプラットフォームによって異なります。たとえば、Cで作業しながらさまざまなデータベースを使用するのは簡単です。適切なライブラリを使用するだけです。
言語は標準の実装を維持する必要があります。これは通常、誰かが構築したいものを構築できるようにするために必要な最小限の量を提供することを意味します。それ以外はすべてライブラリになるか、おそらく他の人が管理する言語の拡張機能になります。
少なくとも、これはISOなどの組織によって確立された標準に従う言語の場合です。
NonStop/C、NonStop/C++、NonStop/Cobol、NonStop/Fortran、およびおそらく他の言語に完全に統合されたNonStop/SQLで動作するために使用され、コンピューターが動作するオペレーティングシステムのNonStop/Guardianと完全に統合されました走った。
これはおそらく、データベースISオペレーティングシステムのファイルシステムです。これは行き止まりであり、コンポーネント、データベースを分離する方法はありません。オペレーティングシステム、ハードウェア、およびそれに記述されているソフトウェアを個別に使用したり、別の環境に移植したりすることはできません。
PCにアクセスするのに最も近いのはMS Accessで、Embarcadero/Borland Delphiが2位です。
その後、アプリケーションの組み込みデータベースを調べます。これは、シンプルな構成ファイルに簡単に保存できない階層データのセットを必要とするスタンドアロンアプリケーションを作成するアプリケーションや、アプリケーションの実行中に定期的な更新が必要なスタンドアロンアプリケーションを作成するユーザーに限定的にアピールできます。 。または、大規模なデータベースの一部のスナップショットを維持し、アプリケーションが接続できるときに大規模なデータベースと同期するポータブルバージョンのアプリケーションが必要な場合（たとえば、手の届かない場所にいるセールスマンが便利な場合があります）企業ネットワークには、顧客グループの売上データ、または患者の記録が必要であるが、行く必要のあるネットワークアクセスがないために病院のネットワークに接続できない現場の医師が必要です）。
以前のVisual Foxpro開発者として、リレーショナルモデルを言語の一部として定義する主流の言語がないのは奇妙なことです。
完全なデータベースエンジンを使用することは良い考えではありませんが、代わりに「SQL」言語を使用すると非常に便利です。
OOでは、インピーダンスのミスマッチが存在します。これは、オブジェクトとセットが互いに似ていないために発生しました。ただし、言語でTABLES、FIELDS、RELATIONS、CONSTRAINSなどを定義できる場合（特定のストレージに関連付けずに）は非常に強力です。さらに、ORMを作成すると、より1対1のマッピングになります。
上記の反例が示したように、書かれているように、質問は部分的に間違っています。
それで、まず、「DBMSが通常、汎用の高水準プログラミング言語の機能として統合されていないのはなぜですか？」という質問を絞り込みます。
これは、オペレーティングシステム、ファイルシステム、Webサーバー、キャッシングレイヤーなどの他のソフトウェア製品が通常組み込まれていないのと同じ理由でです。汎用言語は一般に、そのような製品よりも高い抽象化レベルで動作します。したがって、プログラマーがDBMS in汎用言語を実装することは合理的であり、DBMSは、親言語またはDBプログラマーが使用するためのDB固有の宣言型言語の側面を公開することさえできます。しかし、DBMSを作成する設計オプションが多すぎて、汎用プログラミング言語で修正するのが賢明ではありません。それらを修正すると、MUMPSのようなケースが発生します。この2つの絡み合いにより、業界全体が鶏と卵の問題に陥り、時代遅れのDBMSと時代遅れのプログラミング言語で立ち往生します。