Collections or embedded documents in MongoDB
Yes, related special thoughts

This is what I did:

{
    'name': '苹果',
    'category1': '生鲜',
    'category2': '水果'
}

Easy to search and rank

If the embedded document create/delete/update/ is operated frequently, and there are requirements for sorting when fetching data, it is better to have it at most three levels, and do not embed it too deeply.
I'm out now because of some collection 内嵌得太多，导致很多操作相当不方便，所以又得花很多功夫来把它们 extract.
Of course, if you only want to store data once and the data operations are mainly reading, you don't need to think so much.
Like the course article classification you proposed, if I understand the requirements correctly, can it be like this:

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

degree表示课程类别中的级数，这样一个文章在课程内的类别在读的时候按照 degree to read. For example, an article is "Newton's Second Law" and its course classification is (Physics -> Force). Then save it as:

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

Press category 的 degree 来 sort when reading data.

This is actually a design trade-off, and it has nothing to do with mongdb. Even mysql still needs to think about this issue!
Personally, I feel that we still have to start from the business point of view and think about whether the business data to be analyzed meets the constraints, for example, whether it requires real-time consistency or final consistency.

On another level, for mongdb itself, its embedded documents are not much different from ordinary documents. However, if the embedded document you want to add is one that changes frequently, especially if there is no limit on the size, it is more appropriate to use association. !

Category can be defined as a nested document because you won’t update it often.

Use quotes.