NoSQLデータベース設計のベストプラクティス

NoSQLドキュメントベースのデータベース（MongoDB）を使い始めたばかりで、データベース設計のベストプラクティスに興味があります。

アーキテクチャはリレーショナルデータベースとは異なるはずだと思いますか？正規化されたデータベースを引き続き目指すべきですか？

たとえば、特定のユースケースがあります。

レンタル履歴（アドレスの配列）を持っているユーザーがいますが、その配列はユーザ​​ーの配列であるか、共有キーを持つ個別のコレクションですか？

NoSQLデータベース設計のための適切なアプローチはDDD（ドメイン駆動設計）です。RDBMSの設計に使用していた一部の人々にとって、NoSqlはSqlアンチパターンのように見え、DDDのスコープで考えるとより意味があります。

住所の用途に応じて、レンタル履歴モデル/エンティティ内の値オブジェクトとして定義できます。

ここに、NoSQLを使用した設計に関する考えを明確にする可能性のある参考文献を示します。

• NoSQLの管理者ガイド
• Wakanda：モデル駆動型Webアプリケーション用のNoSQL-NoSQLマターズ2012
• NoSQL批判への対応
• ドメインイベントの経験

TL; DR

RDBMSの正規化により、リレーショナルパラダイムの長所を活用できます。

NoSQLの非正規化により、NoSQLパラダイムの長所を活用できます。

長い答え

RDBMSは、ユニークな構造化されたエンティティ（可変または非可変）とそれらの相互関係をモデル化できるため、優れています。これは、エンティティレベルでの作業、プロパティの更新、別のプロパティの挿入、削除などを非常に簡単に行えることを意味します。 RDBMSは、これらすべてを容易にするツールを提供します。それはあなたのために参加し、あなたのためにエンティティ全体のアトミックな変更を処理します。

NoSQLデータベースは、半/非構造化集計および動的エンティティをモデル化できるため、優れています。これは、常に変化するエンティティ、すべてが同じ属性と階層的集合体を共有しないエンティティのモデリングが非常に簡単であることを意味します。

NoSqlをモデル化するには、エンティティと関係ではなく、階層と集計の観点から考える必要があります。そのため、人、レンタル住所、およびそれらの間の関係はありません。レンタル記録があり、それは各人が所有しているレンタル住所を集計します。

一緒に変更する必要があるデータを尋ねる必要があります。他のデータを論理的にグループ化するデータ。あなたの場合、人は良い集合体のように聞こえます。残りのデータへの論理的なエントリポイントは何ですか。

NoSQLでは、独自のものを持つ他のものを持つものを保存します。物事の階層全体を教えてください。必要に応じて変更してみましょう。次に、物の階層全体を変更したものに置き換えます。それがあなたに与えるほとんどすべてです。なぜ便利なのですか？持っているものが、全体として常にやり取りするものの階層である場合。または、大規模に拡張する必要がある場合。

RDBMSが提供する他のすべてのものは、コードとスキーマに手動で実装する必要があります。集計の集計が必要な場合は、コードに参加する必要があります。集約の一部のみが必要な場合は、解析する必要があります。重複したくない場合は、自分で一意性を確認する必要があります。集計などで作業する場合は、独自のトランザクションロジックを実装する必要があります。

したがって、必要なものをすべて備えた1つの大きなテーブルを用意することが、NoSqlを使用する方法です。原子性はそのレベルでのみ保証され、パフォーマンスも保証されるためです。関係を早期に把握することが重要です。これが非正規化です。

RDBMSでは、非正規化によりDBがNoSQLに効果的に機能しなくなります。そのため、通常は反対、つまり正規化が必要です。そうでない場合は、代わりにNoSQL DBを使用する必要があります。両方のビットが必要でない限り。