对于嵌入式文档来说,深度有多深?使用MongoDB设计投票应用程序

问题描述 投票:0回答:1

我正在设计我的第一个MongoDB数据库(如果这是一个简单的问题,请您道歉)以用于投票应用程序。该应用程序的概念是,用户每周可以在一次竞赛中为自己喜欢的歌曲投票,每次竞赛都由一定数量的条目组成。

到目前为止,我的想法是,每个条目都将包含一个艺术家和一个曲目。可以基于指示器的“活跃”将其从“艺术家”相关的轨道列表中拉出。投票将存储在Entry对象中,并且每个Entry对象都属于一个竞赛。最后,每个竞赛将存储X个条目。

我的问题:

如果竞赛集合包含五个条目,每个条目都有自己的艺术家文档,而每个条目又都有自己的嵌入式曲目列表,那么竞赛集会最终变得太复杂或太“嵌入”吗?像这样。

{
    _id: 'contest12345',
    winner: '',
    active: 1,
    startdate: '01162020',
    enddate: '01172020',
    entry1: {
        _id: 'artist1track1',
        votes: 0,
        artist: {
             _id: 'artist1',
             name: 'Artist 1',
             wins: 0,
             active: 1,
             tracks: [
                 { _id: 'track12345', title: 'Title 1', link: "https://soundcloud.com/artist1/track1", active: 1}, 
                 { _id: 'track12346', title: 'Title 2', link: "https://soundcloud.com/artist1/track2", active: 0} 
             ]
        }
    }, 
    entry2: {
        _id: 'artist2track1',
        votes: 0, 
        artist: { ... }
    }, 
    entry3: { ... },
    entry4: { ... },
    entry5: { ... }   
}

我已经进行了一些研究,发现了一些与我的问题相似但不特定的问题,但是不确定什么被认为“太深了”。我想我了解documentation的状态,但仍不确定MongoDB的理想状态。

感谢任何反馈。

mongodb database-design
1个回答
0
投票

[从技术角度来看,文档的限制大小为16MB,通常不会达到此限制。 MongoDB可以处理嵌入的文档,直到嵌套100级为止。这样您的模型就可以了。 5级(或更多)是很平常的。

告诉您选择是否是一个好选择,要复杂得多。答:在文档中说,文档结构的选择是多因素的:

数据建模中的主要挑战是平衡应用程序的需求,数据库引擎的性能特征以及数据检索模式。在设计数据模型时,请始终考虑数据的应用程序使用情况(即数据的查询,更新和处理)以及数据本身的固有结构。

但是MongoDB的优点是,您可以很容易地改变主意,并在创建应用程序时逐步调整模型。

如果您想更深入地了解,[MongoDB大学提供了很好的数据建模入门课程:https://university.mongodb.com/courses/M320/about

© www.soinside.com 2019 - 2024. All rights reserved.