問題タブ [document-oriented-db]

アプリケーションのセッションの有効期限が切れた後もユーザー設定を永続化することを検討していますが、人々の以前の経験に基づいて、リレーショナル データベース (つまり、Oracle、MySql) またはドキュメント指向データベース (つまり、MongoDB、Redis) がこのタスクにより適しているかどうかに興味がありました。ユーザー設定の意味を明確にするために、私の Web アプリケーションは、ウィンドウのサイズと位置、グリッド列の幅と順序、さまざまなウィジェットの状態 (折りたたみ/非表示) など、ユーザーごとにかなり詳細な情報を保存します。折りたたまれたパネル）。現在、アプリケーションのすべての永続性はリレーショナル データベースによって処理されています。

私たちのチームは、Couchbase DB に裏打ちされたアプリケーションの開発を開始しました。私たちの誰もが、SQL を使用しないデータベースを使用するのは初めての経験です。

エンティティの定義を開始し、Couchbase マニュアルで提案されている「タイプ」プレフィックスを使用する慣行を採用しました。

しかし、複合ドキュメント キーを作成するための戦略の選択に混乱していることに気付きました。私たちはカウンターをよく使用しますが、カウンターには独自の書類が必要です。私たちの鍵は複雑になりました:

私たちはさまざまなアプローチを検討してきましたが、この件についてはまだグリーンホーンであり、アドバイスを求めたいと考えています.

階層キーはまったく良いですか? 重要なキーを定義するためのベスト プラクティスを共有できる人はいますか?

ドキュメント指向データベース mongodb と Object Document Mapper (ODM) morphia の使用

3 つの異なるクラスがあるとします。Object、CategoryおよびAction。
これらのオブジェクトはすべてコレクションに格納されます。オブジェクト、カテゴリ、およびアクション。

CategoryとActionの参照ですObject

現在の実装のドキュメントは次のように保存されます。

• Mongo (サーバー/場所)
  • ストア（データベース）
    • オブジェクト(コレクション)
      • オブジェクト(文書)
      • 物体
      • 物体
    • カテゴリー
      • カテゴリ
      • カテゴリ
      • カテゴリ
    • 行動
      • アクション
      • アクション
      • アクション

次の例に示すように、2 つの異なるオブジェクト (この場合はCategoryとAction) を 1 つのコレクションに格納できますか? どちらも身分証明書付き！

• モンゴ
  • お店
    • オブジェクト
      • 物体
      • 物体
      • 物体
    • 設定
      • カテゴリ
      • カテゴリ
      • カテゴリ
      • アクション
      • アクション
      • アクション

http://docs.mongodb.org/manual/reference/database-references/#DatabaseReferences-SimpleDirect%2FManualLinking

2 つのドキュメント間の関係を保存するほとんどすべてのケースで、手動参照を使用します。参照は簡単に作成でき、アプリケーションは必要に応じて参照を解決できます。

mongodb リファレンス ドキュメントで示されているように、次のように DBRef を使用するよりも、手動のリンク/参照を使用する方が合理的です。

DBref を介してリレーションを実装するのは、一見すると非常に簡単です。それとは別に、スキーマで手動参照を最も効率的に実装する方法に関する信頼できるリソースを見つけることができませんでした。提案:

マニュアル参照はどのように実装する必要がありますか? 挿入の例も示していただければ幸いです。

私は、法的文書を半構造化された方法で保存するシステムを開発しています。MongoDB (または別のドキュメント指向の DB) が最適なオプションですか?. このシステムにより適切な NoSQL タイプはありますか?

私が知っているスキーマレスのプロジェクトにCouchbase Liteデータベースを使用しています。これで問題が解決するので非常に満足していますが、NoSQL（ドキュメントデータベース）の主キー制約に関連する1つの疑問が生じます。

すべてのスキーマ データベースがテーブルで表されることは周知のとおりであり、これらのテーブルにはプライマリ/フォージン キーがある場合とない場合があります。たとえば、usn(大学の座席番号) という主キーを持つ Student というテーブルがあり、その他の属性 (名、姓、住所、連絡先番号など) があるとします。

私たち | ファーストネーム | 姓 | 住所 | 連絡先番号

2BA11CS409 | abc | mnq | バンガロール | 1234567890

2BA11CS410 | xyz | PQR | ムンバイ | ムンバイ 1234567809

ここで、2BS11CS409 値をもう一度追加しようとすると、主キー制約違反 (重複キーを追加できない) というエラーが表示されます。

しかし、文書データベースの場合、文書内の一意の値をどのように識別し、

各ドキュメントには一意の ID が 1 つあり、そのキーはデータベースで検索するためにインデックス化されていることはわかっていますが、上記と同じ値を持つ別のドキュメントを作成すると、

usn を使用して 1 つのデータベースにアクセスしようとすると、1 つのドキュメントだけが返されますが、2 つのドキュメントが返されますが、それらは同一または異なる可能性があります。

リレーショナル データベースに存在するドキュメント データベースの主キー/一意キーの種類の概念を知る必要があります。または、いくつかの記事にリダイレクトできます

ありがとうございました。