Data modeling & partitioning: What every relational database dev needs to know (Ignite 2019)

What people said

Strong rec Mark Brown · 2020-12 · Stack Overflow · on “Do cross-partition queries break infinite CosmosDB horizontal scalability?”

Yes, cross partition queries will not allow a database like Cosmos DB (or any horizontally scalable database) to scale. Databases like Cosmos DB provide unlimited scale because it scales horizontally. The objective for your partition strategy should be to answer your high volume queries with one, or at a minimum, a bounded set of partitions. The effort around partition strategy is to chose a property that is nearly always passed in queries. Denormalization is generally more a function of modeling data around requests. It has less to do with partitioning directly. If you would like to learn more about partitioning and modeling with Cosmos DB I highly recommend watching this video. It presents

Recommends Mark Brown · 2020-12 · Stack Overflow · on “NoSQL database design with one-to-many relationships and picking partition key”

It's rather difficult to answer questions like this and I don't think I can fully answer yours here but I can provide some advice and also point you to resources to help you figure this out yourself. For 1:few relationship you typically will want to embed this. TaxType and LocationType sound like good candidate to embed. However you will want to maintain these in their own container and use ChangeFeed to update them in your TaxAssignments table. For 1:Many relationships, especially if they are unbounded you typically will want to reference this. Not sure if Locations is unbounded in your app. If it isn't then embed this too. Typically you never want to pick a partition key that is never used

Recommends Mark Brown · 2021-06 · Stack Overflow · on “When should a new container be created in CosmosDB?”

The second one is incorrect because to get a post and all its comments you would need to make two requests. One to the post container and one to the comment container.. When designing for a NoSQL database the objective is to reduce the number of requests as much as possible and model and store the data how the application uses it. There is a more recent version of this presentation we did in 2019 that may help explain these concepts better. Recommend watching this one. [this video] There is also a GitHub repository mentioned at the end of this talk that has a deck and demos.

Recommends kamil_k · 2022-01 · Stack Overflow · on “What partition key to choose in cosmos db with little data and one customer per database?”

I would highly recommend you first take a look at this segment of the Data Modelling & Partitioning presentation [this video] by Thomas Weiss, Cosmos DB program manager. In my view it's one of the best resources to understand how to think about partitioning. Do agree with David Makogon that you didn't provide enough data. For instance, we know there are 30 doc types per single database - given cosmosdb database uses containers, I actually expect each docType to have its own container - contrary to what you wrote: Would it make more sense to use customerId (so all data is in one partition) or docType as a partition key? Which suggests you want to use a single container for all your data. I wouldn'

Recommends Mark Brown · 2022-06 · Stack Overflow · on “Rsu same fro primary key and non-primary key - cosmos”

At small sizes the choices you are making here likely won't have any impact either way on RU/s costs. It's only when you want to scale your workload that design decisions you make will have an impact. If you are new to Cosmos DB, I would recommend you watch this presentation on how to model and partition data in Cosmos DB. [this video]

Cites dawids8 · 2022-05 · Stack Overflow · on “Embedded 3 tables in Entity Framework Core and Cosmos DB”

You can store it in one nested document or separately in the same partition but you will need to link them together using an id from a parent to a child document, e.g: public class AppointmentRegisterDetail { public Guid Id { get; set; } = Guid.NewGuid(); public Guid AppoinmentRegisterID { get; set; } ...the rest fields } public class NailsServices { public Guid Id { get; set; } = Guid.NewGuid(); public string AppointmentRegisterDetailId { get; set; } ...the rest fields } It depends on how your application will work with the data, whether you are planning to retrieve them always together or separately. You can also take a look at the model and partition data tutorials. Maybe it will help you

Cites Mark Brown · 2022-08 · Stack Overflow · on “Many to many relation in Cosmos DB + EF Core”

Lots to unpack here. Let's start with your assumptions: updates reference lists automatically when they're changed without need of reacting to Change Feed events as well as keep references consistent This is incorrect. Changes to master data such as tags or symptoms (which I assume as stored in a different container), materialized in your diseases container do not get updated in the container with the master data, or in the container where they are materialized, when either of these are changed. There is no magic bullet or hidden hand here keeping data in sync. Change feed is the mechanism by which you maintain referential integrity for data between containers. automatically makes JOINs (or