Identyfikowanie wzorców dostępu dla aplikacji

  • 3 min

Podczas projektowania modelu danych dla bazy danych NoSQL celem jest zapewnienie, że operacje na danych są wykonywane w najmniejszych żądaniach. W tym celu należy zrozumieć relacje między danymi i sposobem uzyskiwania dostępu do danych przez aplikację. Te wzorce dostępu są ważne, ponieważ wraz z relacjami określają, w jaki sposób właściwości różnych jednostek są grupowane i przechowywane w dokumentach w kontenerach w usłudze Azure Cosmos DB for NoSQL.

W usłudze Azure Cosmos DB for NoSQL dokumenty są nazywane elementami, a kontenery są często nazywane kolekcjami.

Identyfikowanie wzorców dostępu dla jednostek klientów

Zacznijmy od jednostek klientów w naszej bazie danych handlu elektronicznego. Na poniższym diagramie przedstawiono trzy jednostki i relacje między nimi. Trzy jednostki to Customer, CustomerAddress i CustomerPassword. Jednostka Customer ma relację 1:Many z CustomerAddress. Klient ma relację 1:1 z CustomerPassword.

Diagram przedstawiający model relacyjny dla jednostek klientów.

W naszej aplikacji wykonamy trzy operacje na jednostkach klienta:

  • Tworzenie klienta: gdy nowy użytkownik najpierw odwiedza witrynę handlu elektronicznego, zostanie utworzony nowy klient.
  • Aktualizowanie klienta: gdy istniejący użytkownik zaktualizuje informacje o swoim profilu, jego rekord klienta zostanie zaktualizowany.
  • Pobieranie klienta: gdy istniejący użytkownik odwiedza witrynę, zaloguje się przy użyciu swojego hasła. Podczas tej samej sesji będą musieli uzyskać dostęp do innych danych klienta (takich jak adres), aby kupić nowe elementy.

W przypadku każdej z tych operacji potrzebujemy jednocześnie wszystkich tych danych. Jeśli zostały one modelowane jako oddzielne dokumenty, wymagałoby to wielu rund na serwerze do tworzenia, aktualizowania i pobierania danych klienta. Jest to nieefektywne.

Modelowanie jednostek klientów

Usługa Azure Cosmos DB przechowuje dane jako dane JSON, dzięki czemu możemy modelować relację 1:Wiele między klientem a customerAddress i osadzać dane adresów klientów jako tablicę. W przypadku relacji 1:1 między klientem i klientemPassword możemy osadzić to jako obiekt w nowym dokumencie pojedynczego klienta. Następnie aplikacja do handlu elektronicznego może tworzyć, edytować lub pobierać dane klientów w jednym żądaniu.

Na poniższym diagramie przedstawiono wygląd jednostki klienta.

Diagram przedstawiający modelowany dokument klienta.