Exam DP-420 topic 1 question 20 discussion

B. Create a user container that uses the user ID as the partition key and a company container that uses the company ID as the partition key. Add the company ID to each user document. This design separates the users and companies into two different containers, with each container optimized for querying their respective entities. The user container uses the user ID as the partition key, which allows for efficient retrieval of individual users. The company container uses the company ID as the partition key, which enables efficient retrieval of all users associated with a particular company. Adding the company ID to each user document in the user container allows for easy and fast querying of users by company. Whenever a company or user profile is selected, the details page for the company and all related users can be retrieved by joining the data from the two containers using the company ID. This design meets all the requirements specified in the prompt, including efficient reading of data, browsing by company, and browsing users by company.

1000 users with more than 2kb data can still exceed the 2MB allowed document size (dont forgot the company itself has data), so D is obviously incorrect.

1 container and companyID as partitionKey to avoid cross-partition queries, and separate documents to avoid hitting the 2Mb limit (1000 users * 2KB)

D. In a company container, create a document for each company. Embed the users into company documents. Use the company ID as the partition key. Here's why: Efficiency in Data Retrieval: By embedding user data directly into the company document, all relevant user details can be fetched in a single query using the company ID. This aligns with the requirement to display a company's details and all related users on the details page. Optimized for Read Operations: Embedding ensures that browsing by company or browsing users within a company doesn't require multiple queries or complex joins. This makes the design highly performant for read-heavy operations. Scalability: Since each company has less than 1,000 users, embedding users into a company document won't exceed size or scalability limits of most document databases. This approach is particularly effective when the use case prioritizes read performance and browsing-related data access patterns.

Somebody has mention the limit.. But the limit of the document is up to 2MB not 2KB https://learn.microsoft.com/en-us/azure/cosmos-db/concepts-limits

definitely A

I've changed my mind to A. A would not have the risk of hitting the 2mb size limit whilst also maintaining in partition queries based on the companyID partition key.

D. Last statement says it should be optimized for reads. reads with embedded documents is most efficient and less compute resource intensive.

option B is the most suitable design to optimize the data store for reading data Partitioning data based on the company ID for companies and the user ID for users allows for efficient retrieval of data. When querying for a specific company or user, the partition key helps direct the query to the appropriate partition, minimizing the amount of data that needs to be scanned.

A is correct, since the company and users will be in the same partition ang can be retrived in an optimized way. You can use type property to query for the companies only, or users only. B is incorrect since users are partioned by userid and when retrieving users for a company it will be a cross-partition query (not optimal way) D will create large company documents and it is not an optimal way again. C again is not an optimal way since the query to get user by company will run cross partition.

D is correct

B seems to be more optimized for reading data

none of the options address "Associate each user to only one company". Ideally there should be a hierarchical key of userid / companyid to meet this requirement

Option D provides a well-optimized data store design that enables efficient browsing and retrieval of data by company, as well as an easy way to view company details and associated users on a single page.

A is correct … We want users and companies on the same partition. This is done by using company id as partition key for both. As a compayid is a widely used filter thes data that are related can be covered from the same partition. we add a type pro to distinguish the two types

D is correct answer. Googled other sites and they are showing D as answer.