Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Conception d'un schéma de paiements récurrents dans DynamoDB

Cas d'utilisation métier de paiements récurrents

Ce cas d'utilisation traite de l'utilisation de DynamoDB pour implémenter un système de paiements récurrents. Le modèle de données comprend les entités suivantes : accounts (comptes), subscriptions (abonnements) et receipts (reçus). Notre cas d'utilisation présente les spécificités suivantes :

Diagramme des relations entre entités pour les paiements récurrents

Il s'agit du diagramme des relations entre les entités (ERD) que nous utiliserons pour la conception du schéma du système de paiements récurrents.

Modèles d'accès du système de paiements récurrents

Voici les modèles d'accès que nous allons prendre en considération pour la conception du schéma du système de paiements récurrents.

Conception du schéma pour les paiements récurrents

Les noms génériques PK et SK sont utilisés pour les attributs de clé afin de permettre le stockage de différents types d'entités dans la même table, comme les entités account, subscription et receipt. Pour commencer, l'utilisateur crée un abonnement et accepte ainsi de payer un montant le même jour de chaque mois en contrepartie d'un produit. Il a la possibilité de choisir le jour du mois auquel le paiement sera effectué. Un rappel sera également envoyé avant l'exécution du paiement. L'application fait appel à deux tâches de traitement par lots qui s'exécutent chaque jour : l'une qui envoie les rappels programmés à cette date et l'autre qui traite les paiements prévus ce même jour.

Étape 1 : Traitement du modèle d'accès 1 (createSubscription)

Le modèle d'accès 1 (createSubscription) est utilisé pour créer dans un premier temps l'abonnement ; les détails comme SKU, NextPaymentDate, NextReminderDate et PaymentDetails sont également définis. Cette étape indique l'état de la table pour un seul compte avec un seul abonnement. Il peut y avoir plusieurs abonnements dans la collection d'articles, il s'agit donc d'une one-to-many relation.

Étape 2 : Traitement des modèles d'accès 2 (createReceipt) et 3 (updateSubscription)

Le modèle d'accès 2 (createReceipt) est utilisé pour créer l'élément de reçu. Une fois que le paiement mensuel a été effectué, le processeur de paiements écrit un reçu dans la table de base. Il peut y avoir plusieurs reçus dans la collection d'articles, il s'agit donc d'une one-to-many relation. Le processeur de paiements met également à jour l'élément d'abonnement (modèle d'accès 3 (updateSubscription)) afin de mettre à jour NextReminderDate ou NextPaymentDate pour le mois suivant.

Étape 3 : Traitement du modèle d'accès 4 (getDueRemindersByDate)

L'application traite les rappels de paiement par lots pour la date du jour. L'application doit donc accéder aux abonnements selon une autre dimension : la date et non le compte. Il s'agit d'un bon cas d'utilisation pour un index secondaire global (GSI). Dans cette étape, nous ajoutons l'indexGSI-1, qui utilise le NextReminderDate comme clé de GSI partition. Il n'est pas nécessaire de répliquer tous les éléments. Il s'GSIagit d'un indice clairsemé et les éléments des reçus ne sont pas répliqués. Il n'est pas non plus nécessaire de projeter tous les attributs ; il suffit d'inclure un sous-ensemble d'attributs. L'image ci-dessous montre le schéma de GSI-1, qui contient les informations dont l'application a besoin pour envoyer l'e-mail de rappel.

Étape 4 : Traitement du modèle d'accès 5 (getDuePaymentsByDate)

L'application traite les paiements par lots pour la journée en cours de la même manière qu'elle le fait pour les rappels. Nous ajoutons GSI-2 cette étape, et elle utilise le NextPaymentDate comme clé de GSI partition. Il n'est pas nécessaire de répliquer tous les éléments. Il s'GSIagit d'un indice clairsemé car les éléments des reçus ne sont pas répliqués. L'image ci-dessous montre le schéma de GSI-2.

Étape 5 : Traitement des modèles d'accès 6 (getSubscriptionsByAccount) et 7 (getReceiptsByAccount)

L'application peut récupérer tous les abonnements d'un compte en utilisant une requête sur la table de base qui cible l'identifiant du compte (lePK) et utilise l'opérateur de plage pour obtenir tous les éléments dont le numéro SK commence par « SUB # ». L'application peut également utiliser la même structure de requête pour récupérer tous les reçus en utilisant un opérateur de plage pour obtenir tous les éléments dont le numéro SK commence par « REC # ». Cela nous permet de satisfaire les modèles d'accès 6 (getSubscriptionsByAccount) et 7 (getReceiptsByAccount). L'application utilise ces modèles d'accès pour permettre aux utilisateurs de consulter leurs abonnements en cours et leurs anciens reçus des six derniers mois. Lors de cette étape, aucune modification n'est apportée au schéma de table, et nous pouvons voir ci-dessous que seuls les éléments d'abonnement sont ciblés dans le modèle d'accès 6 (getSubscriptionsByAccount).

Tous les modèles d'accès et la façon dont ils sont traités par la conception du schéma sont résumés dans le tableau ci-dessous :

Schéma final pour les paiements récurrents

Voici les conceptions du schéma final. Pour télécharger cette conception de schéma sous forme de JSON fichier, consultez les exemples DynamoDB sur. GitHub

Table de base

GSI-1

GSI-2

Utilisation de No SQL Workbench avec cette conception de schéma

Vous pouvez importer ce schéma final dans No SQL Workbench, un outil visuel qui fournit des fonctionnalités de modélisation, de visualisation des données et de développement de requêtes pour DynamoDB, afin d'explorer et de modifier davantage votre nouveau projet. Pour commencer, procédez comme suit :