MongoDB のコレクションまたは埋め込みドキュメント
はい、関連する特別な考えがあります

これが私がやったことです:

検索とランキングが簡単

埋め込まれたドキュメント create/delete/update/ が頻繁に動作し、データを取得するときに並べ替えの要件がある場合は、最大 3 レベルにし、あまり深く埋め込まない方がよいでしょう。
現在、いくつかの collection が埋め込まれすぎているため、多くの操作が非常に不便であるため、それらを extract するのに多大な労力を費やす必要があります。
もちろん、データを 1 回保存するだけで、データ操作が主に読み取りである場合は、それほど考える必要はありません。
あなたが提案したコース記事の分類のように、要件を正しく理解していれば、次のようになりますか: create/delete/update/ 操作较频繁的话，而且取数据时还有排序的要求，最多至三级比较好，不要内嵌太深。
我现在因为一些 collection 内嵌得太多，导致很多操作相当不方便，所以又得花很多功夫来把它们 extract 出来。
当然，如果你只是为了一次性存数据，对数据的操作以读为主，就不用考虑这么多。
像你提出来的课程文章分类，如果我没理解错需求的话，可不可以这样：

"_id"：
"name" : 
"category" : [ 
    {
        "_id" : 
        "name" : 
        "degree" :
    }, 
    {
        "_id" : 
        "name" : 
        "degree" :
    }, 
]

degree表示课程类别中的级数，这样一个文章在课程内的类别在读的时候按照 degree 来读取。例如，一篇文章为《牛顿第二定律》，它的课程分类为（物理->力）。那么就存为：

"_id"：
"name" : 
"category" : [ 
    {
        "_id" : 
        "name" : '物理'
        "degree" : 1
    }, 
    {
        "_id" : 
        "name" : '力'
        "degree" : 2
    }, 
]

读数据的时候按 category 的 degree 来 sort リーリー

これは実際には設計上のトレードオフであり、mongdb とは何の関係もありません。mysql でもこの問題について検討する必要があります。
個人的には、分析するビジネスデータが制約を満たしているかどうか、たとえばリアルタイムの整合性が必要なのか、最終的な整合性が必要なのか、ビジネスの観点から考える必要があると感じています。

別のレベルでは、mongdb 自体の埋め込みドキュメントは通常のドキュメントとあまり変わりませんが、追加する埋め込みドキュメントが頻繁に変更されるものである場合、特にサイズに制限がない場合は、より適切です。協会を使用します。

カテゴリは頻繁に更新しないため、ネストされたドキュメントとして定義できます。

引用符を使用します。