我使用的是Azure DocumentDB,我在NoSql中的所有经验都在MongoDb中。我查看了定价模型,成本是每个集合。在MongoDb中,我将为我正在使用的用户,公司和电子邮件创建3个集合。我注意到这种方法每月会花费24美元。同档vs异构documentdb
我跟我一起工作的人告诉我,我做错了。我应该将所有这些事情都存储在一个集合中,并用一个字段来描述数据类型是什么。每个馆藏应该按照日期或地理区域相关,因此世界的一部分有一小部分要搜索。 和:
“合并不同类型的文件合并为一个集合,并添加 现场所有他们在寻找像一个类型字段或 东西分开”
我永远不会有梦想在Mongo中这样做,因为它会使索引,分片键和其他事情难以理顺。
有可能不是这些对象之间的重叠可能字段:
我可以做这种方式(例如电子邮件和坚定的对象),但我似乎无法找到任何人做一个例子这样 - 这表明,也许这是不对的。现在,我不需要一个例子,但是有人能够指向某个位置来描述哪种方法是“正确”的方式吗?或者,如果您确实为所有数据创建了单个集合(除了Azure的定价模型),那么这样做的优缺点是什么?
关于DocumentDb模式设计的任何好的文章?
没有“正确”或“错误”的方式(尽管你的同事告诉你)。话虽如此:人们总是将内容组合成单个集合,包括MongoDB(不知道为什么你不会想到这一点,或者为什么这会使索引变得更加困难;索引是基于每个属性的)。借助CosmosDB,它可以让您进行成本优化,并允许您在单个事务中访问异构数据。 –
我不会梦想将入站电子邮件和用户或公司放在一个集合中。我会把这个集合称为什么? “熔炉”?我的意思是,数据甚至与什么方式有关?这些电子邮件确实有电子邮件地址,并可能映射到用户,但它似乎不是一个好技术。另外,你会如何碎片?而且你会在两个对象的每个字段上都有一个索引。 –
此外,这个问题还有更多关于如何设计DocumentDB模式的好消息 - 显示每个模式的优缺点,而不是专门寻找'X是正确的答案' –