プログラミングとデータベースクエリの統合
C++やJavaなどのオブジェクト指向プログラミング言語の一般的なチュートリアルを検討してください。アカウント、注文、アイテムなど（または多かれ少なかれ同等のもの）を表すオブジェクトを使用して、単純な注文処理システムを作成します。完全に直感的に理解できますが、ダイニングテーブルにいる象は、メモリ内のオブジェクトであるため、現実のものではないということです。実際のシステムでは、アカウント、注文など実際にはメモリに存在しないそもそもデータベースに存在し、メモリの表現はその寿命の短いミラーのみです。
自分で大量のコードを作成してデータベースの読み取りと書き込みを行うこともできますが、これは面倒でエラーが発生しやすいため、実際には誰も行いません。
誰もがORMを使用することになりますが、それらはそれ自体が非常に問題があるため、有名な論文では「業界のベトナム」と呼ばれています。
オブジェクトとリレーショナルの間の不一致は、プログラミング言語とデータベースが互いに知らない別々の物であるの間の不一致ほどではないと思います。推測：解決策は、プログラミング言語とデータベースクエリ言語の両方である単一の言語を使用することです。その場合、言語ランタイムもデータベースであり、JITコンパイラーもクエリオプティマイザーである必要があります。
以上が、私が目にする問題の要約です。私の質問は、まだ誰かがいますか、
実際にそのような統一されたシステムを構築しました
このような統一されたシステムを構築しようとしましたが、失敗しました
あなたがそのようなものをどのように構築しようとするのか、あるいはなぜまたはなぜそうでないのかというトピックについて重要なことを書いてください
問題を解決する別の方法を考え出しますか？
これは私の意見。あなたがどこから来たのかはわかりますが、それがデザインの観点から起こっているのを見ることができません。
データの永続化は非常に複雑なテーマです。プログラミング言語も同様です。 2つを組み合わせると、複雑さが爆発的に増加します。両方を実際に使用したい人にとって十分なものにするためには、多くの努力が必要です。すでに述べたと思います [〜＃〜]おたふく風邪[〜＃〜] は良い例です。または、完全な言語が追加されたさまざまなSQLバリアントを確認することもできます。使えるかもしれませんが、喜んで使ってくれるとは思いません。
したがって、それらを分離することは、この複雑さを解決する方法の明確な方法です。また、それらを結び付けないことにより、時間の経過とともに両方を変更および進化させることができます。たとえば、SQLは古く、作成されてからそれほど変わっていません。しかし、アプリケーションの実行に使用される言語は、同じ時期に劇的に変化しました。そして今、反対が起こっています。データベースが変更され進化している間、言語はほとんど同じままです。
ランタイムの配置は別の問題です。 2つを組み合わせると、データベースとアプリケーションまたはWebサーバーの両方が同じプロセスで実行される必要があります。これは、メンテナンスの観点からも、別のコンピューターで実行する機能からも、多対1の関係で実行する機能からも、非常に制限されています。
2つのモジュールを明確なAPIで個別のモジュールに分割することは、複雑さを抑え、使用したいテクノロジーと最終的な部分のデプロイ方法に柔軟性を与える最良の方法です。
あなたはいくつかの主要な仮定をしているようです。たとえば、誰もがリレーショナルデータベースに書き込みをしていると仮定します。それだけではありません。ネイティブプログラミング言語を使用してすべてのコードを記述し、永続性を管理する他のフレーバーのデータベース（オブジェクトデータベース、ドキュメントデータベースなど）の例がたくさんあります。
たとえば、Db4OはJavaとC＃、JavaのObjectDB、さまざまな言語のVelocityDBの両方と互換性があります。MongoDBのドライバーはすべて、ネイティブプログラミング言語で作成することになります（ボーナスJavaScriptを実行しています。これは、シェルでも同じ構文が使用されることを意味します）。
さまざまな場所で多くの議論があり、どのコンテキストでどのDBエンジンが優れているか、そしてなぜこの回答の範囲では多すぎるのか このサイトに閉じた質問を含めることができないのか。 結果は、それぞれが異なるものに対して最適化され、最近までSQLはビジネスアプリケーションにとって一種の「最も一般的な基準」と見なされていました。 ACIDとパフォーマンス（アーキテクチャと要件の変更に伴い、どちらも最近変更されています）。
また、実際には以前から「オールインワン」の種類のアプローチが数多くあったことも注目に値します。メインフレーム言語には、多くの場合、独自の永続化ロジックが組み込まれており、コードとデータをまったく区別しないSmalltalkなどの言語があります。繰り返しになりますが、これらは多くの場合、すべてではなく一部のユースケースに適しています。
はい（私ではありません）。これは [〜＃〜] mumps [〜＃〜] と呼ばれていました。
これ この以前のSE.SEの質問 または この記事 によると、MUMPはあまりうまく設計されていませんでした。しかし、これは実際に医療業界で使用されていた（そしてそれを使用している既存のシステムがあると思います）ので、完全な障害ではありません。
あなたはきっとあなたはそれについての情報を見つけるでしょう。あなたは今何を検索すべきか知っています。上記のWikipediaリンクから始めます。
オブジェクト指向データベースを検索します。それらの多くは言語固有です。彼らはORMよりも簡単な方法でオブジェクトとリレーショナルのミスマッチに対処しようとしました。
実際、データベースとプログラミング言語を単一の環境に統合する複数のシステムがあります。
Smalltalkはおそらくあなたの説明に最も近いものです。メモリ内のオブジェクトは「イメージ」に永続化されるため、言語環境をそのまま（オブジェクト）データベースとして使用できます。また、ほとんどの現代の言語には、組み込みの永続化メカニズムが組み込まれています。つまり、言語環境内のオブジェクトは、言語自体を使用して永続化およびクエリできます。
これは、シングルユーザーアプリケーションに非常に便利です。しかし、同じメモリ空間を共有する必要があるため、このアプローチは複数のユーザーに拡張されません。これは明らかにユーザー数に制限を課します。スケーラブルなソリューションには、並行性を管理する別個のデータベースサーバーが必要です。それでも、特定の言語環境と統合して、言語自体でオブジェクトを永続化およびクエリできる複数のNoSqlデータベースがあります。
リレーショナルな側面から見ると、SQLのスーパーセットである本格的なプログラミング言語であるT-SQLなどの言語があるため、クエリとDMLを任意の複雑な手続き型ロジックと混在させることができます。 T-SQLを使用して複雑なビジネスアプリケーションが構築されているので、これは確かに実行可能ですが、現在の傾向は、手続き型のビジネスロジックawayからデータベースへです。
これらの場合、データベースをプログラミング言語と統合し、「インピーダンスの不一致」を回避することは、非常にエレガントで便利です。では、なぜ人々はまだプログラミング環境とは別にリレーショナルデータベースを使用し、ORM-kludgeとの橋渡しを試みるのでしょうか。
データとクエリを特定のプログラミング言語と環境から分離することには、多くの利点があることがわかります。
- データの独立性。ほとんどの組織では、データは実際には複数のアプリケーションによってアクセスされます。ショップには、Webフロントエンド、カスタマーサポートツール、レポートエンジンなどが使用するデータベースがある場合があります。多くの場合、データ自体は長期間存続しますが、アプリケーションは出入りします。データを1つの特定のプログラミング環境に結合すると、特定のプログラミング環境に固定されます。しかし、プログラミング言語は行き来し、データは永遠に存続します。
- アドホッククエリ。データベースのプロンプトを開いてクエリを書き込むことができると非常に便利です。クエリがプログラミング環境に緊密に結合されている場合、これはプログラミングタスクであり、開発者しか実行できません。
- ロックインを回避します。 SQLは標準であるため、複数のベンダーが多かれ少なかれ互換性のあるデータベース管理システムを提供している場合があります。これにより、ベンダーロックインが回避され、製品の比較が容易になります。
- 疎結合。アプリケーションレイヤーとデータベースの間に明確に定義されたインターフェイスがあると、アプリケーションロジックとは無関係にデータベースを調整および最適化できます。
- 共有インターフェース。データベースインターフェイスはアプリケーションロジックから独立しているため、プロファイリング、レプリケーション、分析などに既成のツールを使用できます。
私が何度も頭の中で処理していたのはかなり良い質問です。問題を解決する既存のソリューションの一例は、JavaScriptデータベース（内部エンジンで実行）を使用してWebページ全体を生成できるコントローラーを作成するグラフデータベースArangoDBです。データはJSONを使用してストレージとの間でやり取りされるため、JavaScriptでネイティブにアクセスでき、クエリは埋め込みクエリ言語で行われます。したがって、このケースは、データベースで実行されるようにJavaScriptを拡張する例です。
実際には、データベース構成の欠陥やバグにより貴重なデータが公開されるため、セキュリティ上の理由からこのようなコントローラーを公開しないでください。
私の個人的な意見では、これは良いアプローチであり、データベースが一種のマップ/リデュース機能をサポートしているかどうかを検討します。バランサー）は、機能するアプリケーションを分散データベースで実行します。
- 実際にそのような統一されたシステムを構築しました
はい、私はそれを Sciter で行いました。
Sciterのスクリプトは「 JavaScript ++ 」であり、永続性が組み込まれています。
_var ndb = Storage.open(pathname);
ndb.root = { ... root object ... };
_ここで、_ndb.root_は、JSに関しては通常のオブジェクトです。それからアクセス可能なすべてのプロパティとサブオブジェクトは永続化可能です-必要に応じてDBに保存およびフェッチされます-コードに対して透過的です。
_ndb.root.accounts[2].firstName = "John";
var name = ndb.root.accounts[3].firstName;
_データは、GCサイクル、十分なメモリがない場合、または明示的なndb.commit()呼び出しのいずれかでDBに保存されます。
Storage class には Index class が付随します-一意の/一意でないキーを持つ永続的な順序付けされたオブジェクトコレクション。
機能セットはMongoDBや他のNoSQLデータベースに似ていますが、IDに個別のORMは必要ありません。dbアクセスは純粋にスクリプトによって行われます。
私は絶対にそれを望んでおり、どこから始めればいいのかわかりません。 SQLは見事なものになる可能性があり、（クエリを文字列のコレクションとして作成したり、ORMを禁止したりする代わりに）汎用プログラミング言語でそのすべての機能とトランザクションの保証を正しく持つことができればすばらしいと思います。
私が知っているあなたの考えに近づく唯一のシステムはaquametaと呼ばれます（タグライン：「PostgreSQLに組み込まれたWeb開発スタック」; https://github.com/aquametalabs/aquameta 、 http://aquameta.org ）。アイデア自体より少しクレイジーな紹介ビデオがあります（youtube.com/watch?v=jz74upW7TN0、youtube.com/watch?v=cWGm9eYUYUk&t=29s、youtube.com/watch?v=xRoUQGUmiMg）、クレイジーと言うとき、彼らはPostgres内に独自のエディターと独自のバージョン管理システムを実装したことを意味します。
これはまさにMicrosoftがLINQを発明した理由であると思います。それは数年前からフルスケールで使用されているため、それに関する文献や、ポジティブとネガティブの両方の実際の経験からの反射を簡単に見つけることができます。 （ほとんどの.net開発ショップはそれを採用しています。）
Linqの良い出発点： https://docs.Microsoft.com/en-us/dotnet/csharp/linq/