3

ASP.NET MVC 3 一般管理システム (プロジェクト管理が最初のコンポーネント) から始めています。今、私は RavenDB について少し調べてみましたが、かなり興味深いように思えます。私がそれについて気に入っている最大の点の 1 つは、DB からのデータを処理するために ORM で型を必要としないという事実です。これにより、コードがよりクリーンで高速になります。しかし、過去 6 年以上にわたって MySQL のみを使用してきた背景から、私は自分のデータとの関連性を非常に重視する傾向があります。NoSQL が適していないように思われることがいくつかあります。私はこれらのものをそこに投げ出したいのですが、これらの問題は NoSQL ソリューションで処理できるかもしれません。また、関係性を考えすぎているだけです (このプロジェクトは MySQL で行う必要があるかもしれません)。これらは私が考えている問題です：

  1. 一意の識別子: 多くのことに対して一意の識別子を使用できるようにしたいと考えています。プロジェクトのようなものでは、名前は一意である必要があり、それを使用できますが、プロジェクトの下のタスクになると、タイトルは一意ではない場合があり、これはクォートインクリメントフィールドを使用する場所ですが、RavenDB でそれを行うことができます (私が言えることから）

  2. リンク: status や type などのフィールドに使用すると、外部キーとのリンクを使用するだけです。1対多の関係の場合、外部キー（NoSQLにはありません）をリンクしようとする代わりにテキストを使用できますが、問題があるため、多対多のリンクを使用できます。たとえば、ほとんどのアイテムに 1 つまたは複数のタグを付けることができるタグ付けシステム (ここにあるような) を用意し、それらのタグでアイテムを検索できるようにするつもりです。NoSQLでこれを行う方法はありますか?

RDBMSは本当にここでの仕事に最適なツールですか、それとも「NoSQL」の方法を適切に考えていないだけで、NoSQL（RavenDB）でこれを達成できますか?

4

2 に答える 2

2

私はこれが古い投稿であることを知っています。おそらく、ドキュメントは最初に書かれたときほど良くありませんでした。しかし、他の人がここでつまずいた場合の参考のために：

  1. Raven には、デフォルトで HiLo ドキュメント ID 生成戦略が付属しています。自分で ID を指定せずに新しいドキュメントを保存すると、「projects/1」、「projects/2」などの自動インクリメント ID が取得されます。詳細については、こちらを参照してください。

  2. ドキュメントの関係を処理するさまざまな方法に関する最良のガイダンスは、こちらのドキュメントにあります。あなたが説明した状況では、別のドキュメントはまったく必要ありません。タグ名の文字列配列を各アイテムに埋め込むだけです。ドキュメントはフラットではなく、構造化できます。はい、引き続きクエリを実行できます。

元の投稿以来、これを自分で発見したことを願っています。

于 2012-12-05T18:30:18.393 に答える
0

Ayende は「RavenDB で参照データをモデル化する」という投稿を書きました。これは、Linking に関するいくつかの質問に答えています。参照ドキュメントと他のドキュメントの間にデータのコピーがあり、ドキュメント データベースの冗長性は「問題ありません」。保存した ID またはテキストに基づいて、引き続きインデックスまたはクエリを作成できます。

アドホック クエリを実行する必要がある Accounts Receivable アプリケーションなどのトランザクション システムには、SQL を使用することをお勧めします。ドキュメント データベースでは、どのようにデータをフェッチするかをよく考え、前もってこれらの質問に答えるためにインデックスを作成する必要があります。RavenDB には、データベースで起動されたクエリから学習してキャッシュする動的インデックス作成機能もあります。

項目の大部分がタスクであるプロジェクト管理の場合、RavenDB がニーズに合うと思います。

于 2011-11-23T14:38:35.270 に答える