How is Cosmos DB data supposed to be structured

Question

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

Answer 1

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.