我正处于对现有青年体育联盟网站(www.parochialathleticleague.org)进行全面重新设计的初期阶段,使用Vue.js作为前端,因此需要对后端结构做出最终决定,因此我可以继续进行该项目。在过去的5年中,我们使用带有自定义PHP脚本的MySQL数据库作为中介,以发送,接收和编辑联赛日程表和排名中的数据。
我相信我可以再次有效地使用MySQL,也许可以使用更智能的表结构,但是对于将MongoDB用作该项目而不是NoSQL实验的可能性,我非常感兴趣。我知道,我知道.. Mongo有很多讨厌之处,并且最适合非常特定的用例,但是我认为结识以供将来参考将是一件有趣的事情。
那就是说,如果我决定选择Mongo,我将非常感谢那些有更多经验的人提供的有关该建议用例中数据库性能的期望的见解。具体来说,在组织计划数据时,我将考虑三个潜在的选择。请参见下文(我为每个选项提供了一个游戏数据的示例):
选项1-收藏:“ 2018男篮-沿海2A”
{
"date": "September 7",
"time": "3:30 PM"
"home": "Blessed Sacrament"
"h_score": 0,
"visitor": "St. Columban",
"v_score": 0,
"location": "Blessed Sacrament",
"game_id": 260
}
在上述建议的解决方案中,我将为每个分区创建一个单独的集合。在过去的一个赛季中,篮球运动总共划分了34个部门,因此在此示例中等于34个集合。这意味着更多的组织开销和更多的配置时间,但是逻辑将决定它是最终用户最快的解决方案,因为任何一个部门最多只能容纳约50个游戏。这也是我在现有网站的MySQL解决方案中设置它的方式:每个分区一个表。
选项2-收藏:“ 2018男篮”
{
"date": "September 7",
"time": "3:30 PM"
"home": "Blessed Sacrament"
"h_score": 0,
"visitor": "St. Columban",
"v_score": 0,
"location": "Blessed Sacrament",
"game_id": 260,
"division": "Coastal 2A"
}
在上述提议的解决方案中,我将为每种性别分别收集一个集合,这样只能得到两个集合-一个集合用于所有男孩的篮球比赛,一个集合用于女孩的比赛。就组织和设置而言,这似乎比上面示例中必须创建34个集合要好得多。但是,我不确定最终用户的使用速度会降低多少,因为现在该系列最多可以容纳500款游戏,而不是50款。因此,解析500款游戏来查找一个特定部门中的50款左右游戏在浏览器中呈现该部门的日程安排之前可能是一个问题-或希望根本不会!
选项3-收藏:“ 2018篮球”
{
"date": "September 7",
"time": "3:30 PM"
"home": "Blessed Sacrament"
"h_score": 0,
"visitor": "St. Columban",
"v_score": 0,
"location": "Blessed Sacrament",
"game_id": 260,
"division": "Coastal 2A",
"gender": "boys"
}
在上述建议的解决方案中,我将为特定季节中的所有比赛制作一个集合。这可能意味着总共可能要玩1000场游戏,而且我认为最终用户的速度可能会成为真正的问题。
非常感谢您的想法和建议。在做出最终决定之前,真的会珍惜一些现实世界的反馈。另外,如果您认为我是一个完整的白痴(我不一定不同意!),并且绝对应该为该项目坚持使用SQL,那么我将对以上三个选项(表/行结构)提出相同的问题。非常感谢!
答案 0 :(得分:1)
您需要牢记的一件事是,MongoDB(和大多数文档存储解决方案)中的架构设计通常围绕嵌入文档而展开。因此,最好将游戏本身保留在部门文档中。然后,最好将游戏,团队,球员等的详细信息也包含在内。
当然,您可以规范化数据(就像在关系数据库中一样),但是您可能会依赖于反模式并遇到烦人的性能问题。
每个文件的MongoDB上限为16MB,因此在设计架构时需要牢记这一点。
作为旁注,由于您提到过,所以您具有MySQL背景。如今,MySQL还提供了document store产品,类似于MongoDB(但有一些differences)。在您的情况下,可能需要学习的东西少得多,所以也许您应该看看。
免责声明:我在Oracle的MySQL连接器团队工作。