MongoDBでのデータ設計（コードの扱い）について

Question

NoSQL (MongoDB) でのデータ設計について悩んでいます。

例えば書類申請データがあり、１つの申請に対して「申請中」「承認」「否認」のいずれかのステータスが設定されるとします。

RDBの場合は、以下のように正規化をするとします。

申請ID	申請者	ステータスID
1	佐藤	0
2	佐藤	1
3	山田	9

ステータスID	ステータス名
0	申請中
1	承認
9	否認

この場合JOINをしてステータス名を取得し１つのデータとしてまとめると思います。

これがMongoDBなどのドキュメント指向データベースになった場合は、ステータスをどう持つのが良い設計なのでしょうか。アプリケーションによりけりとしか言えないというような気もしますが……

• ステータスIDとステータス名を持つ場合

{
  "application_id": 1,
  "applicant_name": "佐藤",
  "status_id": 0,
  "status": "申請中"
}

• ステータスをオブジェクトとして持つ

{
  "application_id": 1,
  "applicant_name": "佐藤",
  "status": {
    "id": 0,
    "name": "申請中"
  }
}

• ステータス名のみ

{
  "application_id": 1,
  "applicant_name": "佐藤",
  "status": "申請中"
}

あまり、ステータスIDというフィールドをNoSQLにおいて持つことにメリットを見い出せません。処理中の分岐とかで使うくらいでしょうか。それすらもステータス名でやってしまえば良いような気がしています。

ステータス名をあとから変えたいケースも考えられますがNoSQLであれば保存されているデータもすべて上書きする必要はどうしてもでてくると思うので、これもメリットとしては薄く見えます。

以上よろしくお願いいたします。

Answer 1

あまり詳しくないですが、今までの経験で話しますと。

MongoDBはドキュメントストア型ですから
行をドキュメントと置き換える（ドキュメント内にドキュメントを埋め込める）ことで
スパース（疎データ）に対処できるようになっていますが、
インデックスを明示的に設定する必要がありますし、インデックスの個数にも制限があります。
＃ただしパフォーマンスを考えると、できるだけインデックスは少ないほうが良いので問題にはならない

またその機構上、結合に制約があったり、全文検索に弱いなどという欠点もあります。

仰られるとおり、リレーショナルDBとは違いますので、
ステータスIDとステータス名を持つ場合は、両方持たせるか名称のみ持たせるかになります。
どちらを取るかは、アプリケーション側で簡単に利用しやすい方を選べば良いと思います。
今のところ他のやり方は、見たことがありませんね。

■FYI
MongoDBにおけるスキーマ
MongoDBのスキーマデザインする時の3つのポイント
MongoDBにおける関連（Relation）のスキーマ設計

Comments

[TakahiRoyte]

ありがとうございます。
経験者の方から後押しいただけて安心できました。
参考リンクも非常に勉強になりました。