MongoDBスキーマデザイン

数年前にMongoDBが導入されたとき、宣伝された重要な機能の1つは、「スキーマレス」機能でした。これは、ドキュメントにとってどのような意味がありますか？

MongoDBスキーマ設計では、コレクションに格納されているドキュメントにスキーマを適用しません。 MongoDBは基本的にJSONドキュメントを格納し、各ドキュメントには任意の構造を含めることができます。以下の「連絡先」コレクションの例をいくつか考えてみましょう。保存できるドキュメントは次のとおりです。

{
  'name':'user1',
  'address':' 1 mountain view',
  'phone': '123-324-3308',
  'SSN':'123-45-7891'
}

これで、コレクションに保存されている2番目のドキュメントを次の形式にすることができます：

{
  'name': ' user2',
  'employeeid': 546789
}

これら両方のドキュメントを同じコレクションに保存できるのは非常に便利です。ただし、コレクションからこれらのドキュメントを取得する必要がある場合に問題が発生します。取得したドキュメントにフォーマット1とフォーマット2のどちらが含まれているかをどのように判断しますか？取得したドキュメントに「ssn」フィールドが含まれているかどうかを確認してから、決定を下すことができます。もう1つのオプションは、ドキュメントの種類をドキュメント自体に保存することです。

{
  'type': xxx,
  'name': ....
  ...
}

どちらの場合も、データベースからアプリケーションにスキーマの適用を移動することで達成できました-

常にスキーマがあり、それはどこに実装されているかという問題にすぎません。

適切なインデックスがあれば、問題はある程度軽減されます。クエリの大部分が「employeeid」によるものである場合、取得されたドキュメントは常に2番目の形式であることがわかりますが、このインデックスを使用しない残りのコードでも、上記の問題が発生します。また、mongooseのようなODMを使用している場合は、MongoDB上にスキーマが自動的に適用されます。

この柔軟性の恩恵を受けるアプリケーションはいくつかあります。頭に浮かぶシナリオの1つは、オプションのフィールド/列が多数あるスキーマの場合です。 MongoDBでは、いくつかの列が欠落していてもペナルティはありません。各ドキュメントには、必要なフィールドのみを含めることができます。

ドキュメントの検証

バージョン3.2.x以降、MongoDBは、「バリデーター」構造を使用したスキーマ検証の概念をサポートするようになりました。これにより、さまざまなレベルの検証が提供されるため、適切なレベルを選択できます。バリデーターを使用しない場合のデフォルトの動作は、以前のスキーマレス動作です。通常、コレクションの作成時に「バリデーター」を作成します

db.createCollection( "contacts",
   { validator: { $or:
      [
         { employeeid: { $exists: true }},
         { SSN: { $exists: true } }
      ]
   }
} )

db.runCommand( {
  collMod: "contacts”,
  validator: { $or: [ { employeeid: { $exists: true }}, { SSN: { $exists:true} } ] }
} )