使用RDBMS建模到NoSQL(Cosmos) [英] Modeling with RDBMS to NoSQL(Cosmos)
问题描述
参考:https://blogs.msdn.microsoft.com/premier_developer/2018/01/31/designing-a-cosmos-db-database/
来到分层结构-1与RDBMS中的第三个规范化非常相似.
Coming to hierarchical structure - 1 to Many or many to Many like the third normalization in RDBMS.
我的问题1 ?我们可以在同一个集合中有多个文档，其中的关键字作为关系吗?就像从上面 (书籍和作者在同一收藏夹上)，如果我们明显尝试复制ID时会遇到独特的违规情况.如果每个书籍和作者文档都有多个馆藏，是否有办法加入两个馆藏?
My Question 1? Can we have multiple documents with the key as a relationship on the same collections? like as from above (Book and Author on same collections) if we try obviously we will have unique violation when ID is getting duplicated. If go with multiple collections for each Book and author documents is there a way to Join both collections?
我的问题2 ?当我们进行非规范化建模时(将所有其他相关实体嵌入(
作者，价格，库存等详细信息))，如果我们需要在示例中更改任何嵌入式文档(价格信息已更改)，则需要用所有其他信息替换文档，或通过任何其他方式来更新特定文档(价格文档)哪一个
嵌入在书中)
My question 2? When we go with Modeling with Denormalization (Embedding all other related entity Book (Embedding with
Author, Price, Stock etc detail)), When we need to update any of the embedded documents if the example (Price information is changed) I need to replace the documents with all other information or any other way to update the specific (Price documents which
are embedded on Books)
推荐答案
您好Saravanan，
Hi Saravanan,
是的，您可以在同一分区中拥有相同的文档类型，但是不能共享相同的密钥.您必须设置一个层次结构:
Yes, you can have the same document types in the same partition but cannot share the same key. You must set-up a hierarchical structure:
此方法适用于:
- 一对多或多对多关系
- 相关数据的频繁更改
- 编写单个文档类型的性能
如果您想为每种文档类型设置一个分区，我相信
If you want to set-up a partition for each document type, I believe the hierarchical structure will then include the partition key + ObjectId related to the parent document Id.
平面结构更符合NoSQL方法，并允许每个查询读取或写入单个文档.但是，由于涉及非规范化，因此这种结构中的数据量可能会出现问题.由于数据重复，
在一致性方面也存在一些挑战.在实践中，经常选择两种方法的混合.对于每种文档类型，建议估算:
A flat structure is more aligned with the NoSQL approach and allows to read or write a single document per query. However, because of the denormalization it involves, the quantity of data in such structure can become problematic. Due to the data duplication,
there are also some challenges in terms of consistency. In practice, a mix of the two approaches is often chosen. For each document type, it is recommended to estimate:
- 文档可以有多大?
- 对于数组类型–会有多少个项目?
- 将需要对这种类型的文档执行哪种类型的查询?从性能和可靠性的角度(多分区访问，事务等)是什么意思?
- How big the document can be?
- For array types – how many items will there be?
- What type of query will need to be performed on this type of document? What does it mean from a performance and reliability standpoint (multiple partition access, transactions, …)?
示例:作者文档包含代表独立文档的书籍ID的列表.同样，本书文档引用了作者列表.相反，图像嵌入在作者文档中.
Example: The Author document contains a list of book ids represented as independent documents. In the same way, the book documents reference a list of authors. On the contrary, images are embedded inside the author document.
此外:
Additionally:
您有机会查看Cosmos DB数据迁移工具:
Have yo had a chance to review the Cosmos DB Data Migration Tool:
如果您需要其他信息，请告诉我们.
Please let us know if you require additional information.
此致
迈克
这篇关于使用RDBMS建模到NoSQL(Cosmos)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
