Toegangspatronen voor uw app identificeren

  • 3 minuten

Wanneer u een gegevensmodel ontwerpt voor een NoSQL-database, is het doel om ervoor te zorgen dat bewerkingen op gegevens worden uitgevoerd in de minste aanvragen. Hiervoor moet u inzicht krijgen in de relaties tussen de gegevens en hoe gegevens worden geopend door de toepassing. Deze toegangspatronen zijn belangrijk omdat ze, samen met de relaties, bepalen hoe de eigenschappen van de verschillende entiteiten worden gegroepeerd en opgeslagen in documenten in containers in Azure Cosmos DB voor NoSQL.

In Azure Cosmos DB for NoSQL worden documenten items genoemd en containers worden vaak aangeduid als verzamelingen.

Toegangspatronen voor klantentiteiten identificeren

Laten we beginnen met de klantentiteiten in onze e-commercedatabase. In het volgende diagram ziet u drie entiteiten en de relaties ertussen. De drie entiteiten zijn Customer, CustomerAddress en CustomerPassword. De entiteit Klant heeft een 1:Veel-relatie met CustomerAddress. Klant heeft een 1:1-relatie met CustomerPassword.

Diagram met het relationele model voor klantentiteiten.

In onze toepassing voeren we drie bewerkingen uit op de klantentiteiten:

  • Een klant maken: Wanneer een nieuwe gebruiker de e-commercesite voor het eerst bezoekt, wordt er een nieuwe klant gemaakt.
  • Een klant bijwerken: wanneer een bestaande gebruiker zijn profielgegevens bijwerkt, wordt de klantrecord bijgewerkt.
  • Een klant ophalen: wanneer een bestaande gebruiker de site bezoekt, meldt hij zich aan met zijn wachtwoord. Tijdens dezelfde sessie moeten ze toegang krijgen tot andere klantgegevens (zoals adres) om nieuwe items te kopen.

Voor elk van deze bewerkingen hebben we al deze gegevens tegelijkertijd nodig. Als ze als afzonderlijke documenten zijn gemodelleerd, zijn er meerdere retouren naar de server nodig om de klantgegevens te maken, bij te werken en op te halen. Dit is inefficiënt.

Klantentiteiten modelleren

Azure Cosmos DB slaat gegevens op als JSON, zodat we de 1:Veel-relatie tussen Klant en CustomerAddress kunnen modelleren en de klantadresgegevens als matrix kunnen insluiten. Voor de 1:1-relatie tussen Klant en CustomerPassword kunnen we dat insluiten als een object in ons nieuwe document met één klant. Vervolgens kan de e-commercetoepassing klantgegevens in één aanvraag maken, bewerken of ophalen.

In het volgende diagram ziet u hoe onze klantentiteit eruitziet.

Diagram met een gemodelleerd klantdocument.