NoSQLデータベース設計のベストプラクティス
NoSQLドキュメントベースのデータベース（MongoDB）の使用を開始したばかりで、データベース設計のベストプラクティスに興味があります。
アーキテクチャはリレーショナルデータベースとは異なる必要があると思いますか？それでも正規化されたデータベースを目指すべきですか？
たとえば、私には特定のユースケースがあります。
レンタル履歴（アドレスの配列）を持つユーザーがいますが、その配列はユーザーの配列にする必要がありますか、それとも共有キーを持つ個別のコレクションにする必要がありますか？
NoSQLデータベース設計の適切なアプローチは、[〜＃〜] ddd [〜＃〜]（ ドメイン駆動設計 ）です。 RDBMSの設計に使用していた一部の人にとって、NoSqlはSqlアンチパターンのように見え、DDDのスコープで考えるとより理にかなっています。
アドレスの使用法に応じて、レンタル履歴モデル/エンティティ内の値オブジェクトとして定義できます。
以下は、NoSQLを使用した設計についての考えを明確にする可能性のある参照です。
TL; DR
RDBMSでの正規化により、リレーショナルパラダイムの長所を活用できます。
NoSQLの非正規化により、NoSQLパラダイムの長所を活用できます。
長い答え
RDBMSは、ユニークな構造化されたエンティティ（変更可能かどうかにかかわらず）とそれらの相互関係をモデル化できるため、優れています。これは、エンティティレベルでの作業、プロパティの更新、別のプロパティの挿入、削除などが非常に簡単であることを意味します。ただし、動的にそれらを集約したり、飼い主がいる犬や、家が住んでいる犬などを集めたりするのにも最適です。 。RDBMSは、これらすべてを容易にするツールを提供します。それはあなたのために参加します、それはあなたのためにエンティティ全体のアトミックな変更を処理します、など。
NoSQLデータベースは、半構造化/非構造化集計および動的エンティティをモデル化できるため、優れています。つまり、常に変化するエンティティ、つまりすべてが同じ属性と階層的集計を共有しないエンティティをモデル化することは非常に簡単です。
NoSqlをモデル化するには、エンティティと関係ではなく、階層と集計の観点から考える必要があります。したがって、人、賃貸住所、およびそれらの間の関係はありません。あなたは彼らが持っていたどのレンタルアドレスを各人のために集計するレンタルレコードを持っています。
あなたは尋ねる必要があります、私は一緒に変更する必要があるデータはどれですか？他のデータを論理的にグループ化しているデータ。あなたの場合、人は良い集合体のように聞こえます。残りのデータへの論理的なエントリポイントは何ですか。
NoSQLは、独自のものを持っている他のものを持つものを保存するとしましょう。物事の全体的な階層を返してください。好きなように変更してみましょう。今度は、階層全体を変更したものに置き換えます。それだけで十分です。なぜそれが役立つのですか？あなたが持っているものが、全体として常に相互作用するものの階層である場合。または、大規模なスケーリングが必要な場合。
RDBMSが提供するその他すべてのものは、コードとスキーマに手動で実装する必要があります。集計の集計が必要な場合は、コードに参加する必要があります。集合体の一部のみが必要な場合は、解析する必要があります。重複したくない場合は、自分で一意性を確認する必要があります。集計全体で作業する場合などは、独自のトランザクションロジックを実装する必要があります。
したがって、必要なすべてを備えた1つの大きなテーブルを用意することが、NoSqlへの道です。原子性はそのレベルでのみ保証されており、パフォーマンスも保証されています。関係を早期に理解することが重要です。これが非正規化です。
RDBMSでは、非正規化によってDBが実質的にNoSQLに変換されます。したがって、通常は反対の、つまり正規化が必要です。そうでない場合は、代わりにNoSQL DBを使用する必要があります。あなたが両方のビットを少し必要としない限り。