プログラミングとデータベースクエリの統合[終了]

C ++やJavaなどのオブジェクト指向プログラミング言語の一般的なチュートリアルを検討してください。アカウント、注文、アイテムなど（またはほぼ同等のもの）を表すオブジェクトを使用して、簡単な注文処理システムを作成します。完全に直感的に理解できますが、ダイニングテーブルにいる象は、これらがインメモリオブジェクトであるため、現実的ではないということです。実際のシステムでは、アカウント、注文などはそもそもメモリに実際に存在するのではなく、データベースに存在し、メモリ表現はその短命のミラーにすぎません。

データベースを読み書きするために多くのコードを自分で書くこともできますが、それは退屈でエラーが発生しやすいため、実際に誰もそれを行いません。

誰もがORMを使用することになりますが、それらはそれ自体非常に問題が多いため、有名な論文では「ORMのベトナム」と呼ばれています。

プログラミング言語とデータベースがお互いを知らない別個のものであるのと同じくらい、オブジェクトとリレーショナルの不一致ではないと思います。推測：解決策は、プログラミング言語とデータベースクエリ言語の両方である単一の言語を使用することです。そのためには、言語ランタイムもデータベースであり、JITコンパイラもクエリオプティマイザーである必要があります。

それが私が見た問題の要約です。私の質問は、まだ誰かがいますか、

1. 実際にこのような統合システムを構築しました

2. 試みたが、そのような統合システムの構築に失敗した

3. あなたがそのような建築をどのように進めるのか、またはなぜ、なぜそうでないのかというトピックに関する実質的なものを書かれている

4. 問題を解決する別の方法を思い付きますか？

これは私の意見。私はあなたがどこから来ているのかを見ていますが、デザインの観点からそれが起こっているのを見ることができません。

データの永続化は非常に複雑なテーマです。プログラミング言語も同様です。この2つを組み合わせると、複雑さが増します。両方を実際に使用したい人にとって十分なものにするためには、多大な労力が必要です。すでに述べたMUMPSは良い例だと思います。または、完全な言語がその上に追加されたさまざまなSQLバリアントを見ることができます。それらは使用可能かもしれませんが、人々が喜んで使用するとは思いません。

したがって、これらの分離は、この複雑さを解決するための明確な方法です。また、それらを結び付けないことにより、時間の経過とともに両方を変更および進化させることができます。たとえば、SQLは古く、作成されてからあまり変更されていません。しかし、アプリケーションを実行するために使用される言語は、同じ期間で劇的に変化しました。そして今、反対のことが起こっています。データベースが変更され進化している間、言語はほとんど同じままです。

ランタイム展開も別の問題です。2つを組み合わせると、データベースとアプリケーションまたはWebサーバーの両方が同じプロセスで実行する必要があります。これは、保守の観点から、およびそれらを別々のコンピューター上で、または多対1の関係で実行する能力から、非常に制限されています。

明確なAPIを使用して2つのモジュールを別々のモジュールに分割することは、複雑さを抑え、使用するテクノロジーと最終的なピースのデプロイ方法に柔軟性を与える最良の方法です。

あなたはいくつかの大きな仮定をしているようです。たとえば、誰もがリレーショナルデータベースに書き込みを行っていると仮定しています。それは単にそうではありません。ネイティブプログラミング言語を使用してすべてのコードを記述し、永続性を管理する他のフレーバー（オブジェクトデータベース、ドキュメントデータベースなど）のデータベースの例がたくさんあります。

たとえば、Db4OはJavaとC＃の両方、JavaのObjectDB、さまざまな言語のVelocityDBと互換性があります。MongoDBのドライバーはすべて、ネイティブプログラミング言語（JavaScriptを実行している場合は、シェルも同じ構文を使用することを意味します）などで作成する必要があります。

さまざまな場所で、どのDBエンジンがどのコンテキストで優れているのか、なぜこの回答の範囲に対してあまりにも多くの理由でこのサイトに非公開の質問を含めるのかについて多くの議論があります。結果は、それぞれが異なるものに最適化されていることであり、最近までSQLはビジネスアプリケーションの一種の「最も低い共通分母」とみなされていました最近、アーキテクチャと要件の変更に伴い）。

また、以前は多くの「オールインワン」のアプローチが実際に存在していたことも注目に値します。メインフレーム言語には、多くの場合、独自の永続ロジックが組み込まれています。また、Smalltalkのような、コードとデータをまったく区別しない言語があります。繰り返しますが、多くの場合、それらは一部のユースケースには適していますが、すべてではありません。

1. はい（私ではありません）。ムンプスと呼ばれていました。

2. これによると、この元SE.SEの質問、またはこの記事で、おたふく風邪は非常によく設計されていませんでした。しかし、これは実際に医療業界で使用されていました（そして、それを使用している既存のシステムがまだあると思います）。

3. 検索対象がわかったので、確実に情報を見つけることができます。上記のウィキペディアのリンクから始めてください。

4. オブジェクト指向データベースを検索します。それらの多くは言語固有です。彼らは、オブジェクトリレーショナルの不一致をORMよりも簡単な方法で解決しようとしました。

実際、データベースとプログラミング言語を単一の環境に統合する複数のシステムがあります。

Smalltalkはおそらくあなたが説明するものに最も近いでしょう。メモリ内のオブジェクトは「イメージ」に保持されるため、言語環境はすぐに使用できる（オブジェクト）データベースとして使用できます。また、最新の言語のほとんどには、組み込みの永続化メカニズムが組み込まれているため、言語環境内のオブジェクトを、言語自体を使用して永続化および照会できます。

これは、シングルユーザーアプリケーションにとって非常に便利です。ただし、複数のユーザーが同じメモリスペースを共有する必要があるため、この方法は複数のユーザーに拡張できません。明らかにユーザーの量に制限があります。スケーラブルなソリューションには、同時実行性を管理する別個のデータベースサーバーが必要です。その場合でも、特定の言語環境と統合し、言語自体でオブジェクトを保持およびクエリできるようにする複数のNoSqlデータベースがあります。

リレーショナルサイドから見ると、SQLのスーパーセットである本格的なプログラミング言語であるT-SQLのような言語があるため、クエリとDMLを任意の複雑な手続き型ロジックと混在させることができます。複雑なビジネスアプリケーションはT-SQLを使用して構築されているため、これは確かに実行可能ですが、現在の傾向は手続き型ビジネスロジックをデータベースから離すことです。

これらの場合、データベースをプログラミング言語と統合し、「インピーダンスの不一致」を回避することが非常にエレガントで便利です。では、なぜ人々はいまだにプログラミング環境とは別のリレーショナルデータベースを使用し、ORMクラッジとの橋渡しをしようとしているのでしょうか？

データとクエリを特定のプログラミング言語や環境から分離することには、多くの利点があります。

• データの独立。ほとんどの組織では、実際には複数のアプリケーションがデータにアクセスします。ショップには、Webフロントエンド、カスタマーサポートツール、レポートエンジンなどで使用されるデータベースがあります。多くの場合、データ自体は長命ですが、アプリケーションは行き来します。データを特定のプログラミング環境に結合すると、特定のプログラミング環境にロックインされます。しかし、プログラミング言語は行き来しますが、データは永遠に残ります。
• アドホッククエリ。データベースプロンプトを開いてクエリを作成できると非常に便利です。クエリがプログラミング環境に密接に結合されている場合、これはプログラミングタスクになり、開発者のみが実行できます。
• ロックインを避けます。SQLは標準であるため、複数のベンダーが多かれ少なかれ交換可能なデータベース管理システムを提供する場合があります。これにより、ベンダーロックインが回避され、製品の比較が容易になります。
• 疎結合。アプリケーション層とデータベースの間に明確に定義されたインターフェースを持つことにより、アプリケーションロジックとは無関係にデータベースを調整および最適化できます。
• 共有インターフェース。データベースインターフェイスはアプリケーションロジックから独立しているため、プロファイリング、複製、分析などに既製のツールを使用できます。

頭の中で何度も処理していたのはかなり良い質問です。問題を解決する既存のソリューションの1つの例は、JavaScript（内部エンジンで実行）を使用してWebページ全体を生成できるコントローラーを記述するグラフデータベースArangoDBです。データはJSONを使用してストレージとやり取りされるため、JavaScriptでネイティブにアクセスでき、クエリは埋め込みクエリ言語で実行されます。したがって、このケースは、データベースで実行されるJavaScriptを拡張する例です。

実際には、データベース構成の欠陥やバグにより貴重なデータが公開されるため、セキュリティ上の理由でこのようなコントローラーを公開しないでください。

私の意見では、これは良いアプローチであり、データベースが、集約されたデータ/テキストインデックスおよびその他の頻繁にクエリされるデータをリアルタイムで更新する一種のmap / reduce機能をサポートし、その間に薄いセキュリティレイヤーを追加するかどうかを検討しますバランサー）は、分散データベースで機能するアプリケーションを実行します。

1. 実際にこのような統合システムを構築しました

はい、私はSciterでそれをしました。

Sciterのスクリプトは、永続性が組み込まれた「JavaScript ++」です。

var ndb = Storage.open(pathname);
ndb.root = { ... root object ... };

ndb.rootJSに関しては、通常のオブジェクトはどこにありますか。すべてのプロパティとそこからアクセス可能なサブオブジェクトは永続的です-必要に応じてDBに保存され、フェッチされます-コードに対して透過的に：

ndb.root.accounts[2].firstName = "John";
var name = ndb.root.accounts[3].firstName;

データは、GCサイクル、メモリ不足、または明示的なndb.commit()呼び出しのいずれかでDBに保存されます。

Storageクラスはを伴うIndexクラス -ユニーク/非ユニークキーを持つ永続注文したオブジェクトのコレクション。

機能セットはMongoDBまたは他のNoSQLデータベースに似ていますが、idには個別のORMは必要ありません-dbアクセスは純粋なスクリプト手段によって行われます。

私は絶対にそれであり、どこから始めればいいのか分かりません。SQLは素晴らしいものになる可能性があり、すべての目的のプログラミング言語でそのすべてのパワーとトランザクション保証を正しく持つことは素晴らしいことだと思います（クエリを文字列のコレクションとして記述したり、ORMを使用したりする代わりに）。

私が知っているあなたの考えに近づいて唯一のシステムはaquameta（：;参照「はPostgreSQLに構築されたWeb devのスタック」タグラインと呼ばれる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/