現在、NoSQLデータストアの全体的なアイデアとドキュメントデータベースの概念は非常に新しく、リレーショナルストレージを推進する確立されたアイデアとは異なるため、現在のところベストプラクティスはほとんどありません。
この時点で、たとえばCouchDB（またはその他のドキュメントデータベース）内にデータを格納するためのルールは、リレーショナルデータベースのルールとはかなり異なることがわかっています。たとえば、正規化と3NFの目標化は、努力すべきものではないというのは事実です。一般的な例の1つは、単純なブログの例です。
リレーショナルストアには、「投稿」、「コメント」、「作成者」のそれぞれのテーブルがあります。各作成者には多くの投稿があり、各投稿には多くのコメントがあります。これは十分に機能するモデルであり、任意のリレーショナルDBに適切にマッピングされます。ただし、同じデータをdocDB内に格納することは、おそらくかなり異なります。おそらく、投稿ドキュメントのコレクションのようなものがあり、それぞれに独自の作成者とコメントのコレクションが埋め込まれています。もちろん、それが唯一の方法ではなく、多少の妥協点です（現在は単一の投稿のクエリは高速です。1回の操作ですべてを取り戻すことができますが、作成者と投稿の関係を維持する方法はありません（すべてが投稿ドキュメントの一部になるため）。
私も「type」属性を使用する例を見てきました（CouchDBの例）。確かに、それは実行可能なアプローチのように聞こえます。最高ですか？手がかりがありません。確かに、MongoDBでは、データベース内で個別のコレクションを使用するため、type属性はまったく意味がありません。 CouchDBでは...おそらくそれは 一番。他の選択肢は？ドキュメントの種類ごとに個別のデータベース？これは少しループしているように見えるので、私は自分で「タイプ」ソリューションに傾倒します。しかし、それは私だけです。おそらくもっと良いものがあります。
私はここでかなり歩き回って、ほとんど何も言わなかったことに気づきました。おそらくあなたがまだ知らなかったことは何もありません。私のポイントはこれですが、私たちが持っているツールと使用しているデータを実験するのは私たちの責任だと思います。時間の経過とともに、優れたアイデアが広まり、なります。 ベストプラクティス。ゲームの早い段階で質問していると思います。