5

I am currently working with a team of developers that is implementing CosmosDB as a backend store, and I have some questions about how it is really supposed to be used.

I get that the documents are supposed to be flat structured, but what exactly does that mean.?

When the data is really relational, and very dependant on one another, is this design correct, or would a SQL database be more suited?

RetailProduct

{
    "RetailProductId": "123",
    "FriendlyName": "TestRetailProduct",
    "WholeSaleProductId": "100"
}

WholeSaleProduct

{
    "WholeSaleProductId": "100",
    "ProviderID": "112233445566",
    "PhysicalItemsIds": ["1000", "2000", "3000"]
}

Provider

{
    "ProviderId": "112233445566",
    "Description": "ProviderA"
}

There are many more documents linked from either RetailProduct or the WholeSaleProduct, but this is just to give an overview.

Is storing data like this, considered to be good practice for a database like CosmosDB

monstertjie_za
  • 7,277
  • 8
  • 42
  • 73
  • 1
    Unfortunately there's really no "right" answer to this. Whether you store flat documents or nested documents is going to depend on how you query/update data, how you partition data, etc. And whether a relational database would the better choice? Again, no simple answer (and with the samples you showed, either database type could handle this type of schema). – David Makogon Sep 10 '18 at 18:30
  • 1
    I'd add that when you're getting your head around modeling data in a NoSQL solution, there's a good video by David Makogon and Ryan CrawCour on this topic that helped me. Check out https://channel9.msdn.com/Events/Build/2016/P468. – Rob Reagan Sep 11 '18 at 00:32
  • Hi,if you think my answer helps you, you could mark it for answer,thanks a lot. – Jay Gong Sep 17 '18 at 08:32
  • I tried to give an answer here: https://stackoverflow.com/questions/53852993/how-to-structure-relationships-in-azure-cosmos-db/54015630#54015630 – mauridb Jan 07 '19 at 22:18

1 Answers1

4

Maybe here is not an absolute answer, just for your reference.In fact, your data format does not limits which database you choose, both databases have their pros and cons.

Relational database such as SQL database :

Relational databases excel at handling highly structured data and provide support for ACID (Atomicity, Consistency, Isolation, and Durability) transactions. Data is easily stored and retrieved using SQL queries. The structure can be scaled up quickly because adding data without modifying existing data is simple.

However,the biggest weakness of relational databases is the mirror of their biggest strength. As good as they are at handling structured data, they have a hard time with unstructured data.

Un-relational databases like Cosmos DB:

Document stores are very flexible. They handle semistructured and unstructured data well. Users don’t need to know during set-up what types of data will be stored, so this is a good choice when it isn’t clear in advance what sort of data will be incoming.

NoSQL databases have the ability to incorporate any type of data, without losing any of its scaling abilities and allows users to make changes in real-time.

In additional,cost is also a factor to consider.You could check this thread: Comparison between Azure SQL cost vs DocumentDB/CosmosDB cost.

In my opinion, if your data is almost always structured, the business logic is highly coupled,then I suggest using SQL database. If your data is only partially structured, and the data format is more flexible and easier to scale horizontally, I suggest you use Cosmos DB.

halfer
  • 19,824
  • 17
  • 99
  • 186
Jay Gong
  • 23,163
  • 2
  • 27
  • 32
  • Good answer. I think the only thing you don’t address that he is also asking is the flat or nested documents. If the entities are so tightly coupled they could all sit in a single document however there are two concerns. In this case the user should only select the fields they need to save RUs. Also CosmosDB doesn’t support partial document update yet so even a small property change will cost a write operation of whatever the full size of the document is. – Nick Chapsas Sep 11 '18 at 08:02
  • @NickChapsas Totally agree with your arguments.Thanks for your addition. – Jay Gong Sep 11 '18 at 08:07