3

Java サーバー側アプリケーションのデータベースとして MongoDB を使用することを検討しています。私の以前のプロジェクトでは、Hibernate を使用して基礎となる SQL データベースを抽象化し、アプリケーション コードを変更せずに (たとえば) MySQL から Postgres に切り替えることができました。(これは、通常の ORM 機能とは別に、Hibernate が提供してくれた + でした)。
ドキュメント指向の NoSQL データベースの同様の抽象化レイヤーを検索しましたが、結果はありませんでした。

現在の要件は MongoDB で十分ですが、3 年後により優れたドキュメント指向の NoSQL DB が登場したとしても、アプリケーション コードを変更して新しい DB に移行したくはありません。

解決策の 1 つは、抽象化レイヤーを自分で作成することです (他に選択肢がない場合は、そうします)。

しかし、ORM の世界から来た人々が NoSQL DB インターフェースに直接コーディングしたとしたら、私は驚かれることでしょう?! NoSQL の世界では、データベースの独立性は問題ではありませんか? それとも他の手段で達成されますか？

4

2 に答える 2

6

NoSQL 用の成熟したデータベースに依存しない ORM レイヤーが多くない理由は次のとおりです。

  1. それらは標準化されていません。SQL は ISO 標準です。その標準に固執する場合、基礎となるデータベースを変更するときに少し変更を加える必要があります。ただし、ドキュメント指向のデータベースにはすべて、独自のクエリ言語があります。

  2. それらはすべて根本的に異なる働きをします。すべてのドキュメント指向データベースには、独自の哲学、長所、短所、およびユースケースがあります。CouchDB でうまく機能するストレージ戦略は、MongoDB にはまったく不適切である可能性があります。これらの癖をすべて満たす API の共通分母を見つけることができるほど抽象化できる ORM マッパーを使用するのは困難です。

  3. それらはまだかなり新しい技術です。それらを取り巻くソフトウェア エコシステムが SQL に似た標準に進化するには、まだ数年かかります。

ただし、ドキュメント指向データベースの世界にはデータベースに依存しない ORM のソリューションはありませんが、特定のデータベース用の ORM ラッパーはたくさんあることに注意してください。使用しているプログラミング言語については触れていませんが、ほとんどの主流言語には解決策があります。これは、自分でロールするよりも間違いなく優先されます。

于 2013-05-21T21:10:15.120 に答える
0

mongo を使用している場合は、Spring データを使用できます。また、リポジトリ パターンを実装する必要があります。その方法でも、前述のように、それを可能にするSQLフレームワークほど不可知ではありませんが、これをmvcパターンとして適切なレベルで実装できれば、ソリューションには十分だと思います。

于 2016-05-18T16:47:00.320 に答える