Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Schemadesign für wiederkehrende Zahlungen in DynamoDB
Geschäftsszenario für wiederkehrende Zahlungen
In diesem Anwendungsfall geht es um die Verwendung von DynamoDB zur Implementierung eines Systems für wiederkehrende Zahlungen. Das Datenmodell hat die folgenden Entitäten: Konten, Abonnements und Belege. Zu den Besonderheiten unseres Anwendungsfalls gehört Folgendes:
-
Jedes Konto kann mehrere Abonnements haben
-
Der Abonnement hat ein
NextPaymentDate
, an dem die nächste Zahlung bearbeitet werden muss und einNextReminderDate
, an dem eine E-Mail-Erinnerung an den Kunden gesendet wird -
Es gibt ein Element für Abonnement, das gespeichert und aktualisiert wird, wenn die Zahlung verarbeitet wurde (die durchschnittliche Artikelgröße liegt bei etwa 1 KB und der Durchsatz hängt von der Anzahl der Kontenund Abonnements ab)
-
Der Zahlungsabwickler erstellt im Rahmen des Vorgangs auch eine Quittung, die in der Tabelle gespeichert ist und anhand eines Attributs so eingestellt ist, dass sie nach einer bestimmten Zeit ablaufen TTL
Beziehungsdiagramm für Unternehmen mit wiederkehrenden Zahlungen
Dies ist das Entitätsbeziehungsdiagramm (ERD), das wir für das Systemschema für wiederkehrende Zahlungen verwenden werden.

Zugriffsmuster für das System für wiederkehrende Zahlungen
Dies sind die Zugriffsmuster, die wir für das Schemadesign für das System für wiederkehrende Zahlungen berücksichtigen werden.
-
createSubscription
-
createReceipt
-
updateSubscription
-
getDueRemindersByDate
-
getDuePaymentsByDate
-
getSubscriptionsByAccount
-
getReceiptsByAccount
Schemadesign für wiederkehrende Zahlungen
Die generischen Namen PK
und SK
werden für Schlüsselattribute verwendet, um das Speichern verschiedener Entitätstypen in derselben Tabelle zu ermöglichen, z. B. die Konto-, Abonnement- und Empfangsentitäten. Der Benutzer erstellt zunächst ein Abonnement. In diesem Fall verpflichtet sich der Benutzer, jeden Monat am selben Tag einen Betrag als Gegenleistung für ein Produkt zu bezahlen. Sie können entscheiden, an welchem Tag des Monats die Zahlung bearbeitet werden soll. Es gibt auch eine Erinnerung, die vor der Bearbeitung der Zahlung gesendet wird. Die Anwendung funktioniert mit zwei Batch-Jobs, die jeden Tag ausgeführt werden: Ein Batch-Job sendet Erinnerungen, die an diesem Tag fällig sind, und der andere Batch-Job verarbeitet alle an diesem Tag fälligen Zahlungen.
Schritt 1: Zugriffsmuster 1 (createSubscription
) angehen
Zugriffsmuster 1 (createSubscription
) wird verwendet, um das Abonnement zunächst zu erstellen, und die Details einschließlich SKU
, NextPaymentDate
, NextReminderDate
und PaymentDetails
werden festgelegt. In diesem Schritt wird der Status der Tabelle für nur ein Konto mit einem Abonnement angezeigt. Die Artikelsammlung kann mehrere Abonnements enthalten, es handelt sich also um eine one-to-many Beziehung.

Schritt 2: Zugriffsmuster 2 (createReceipt
) und 3 (updateSubscription
) angehen
Zugriffsmuster 2 (createReceipt
) wird verwendet, um die Belegposition zu erstellen. Nachdem die Zahlung jeden Monat bearbeitet wurde, schreibt der Zahlungsabwickler einen Beleg zurück in die Basistabelle. Die Artikelsammlung kann mehrere Belege enthalten, es handelt sich also um eine one-to-many Beziehung. Der Zahlungsabwickler aktualisiert auch das zu aktualisierende Abonnementelement (Zugriff auf Muster 3 (updateSubscription
)) für den NextReminderDate
oder den NextPaymentDate
für den nächsten Monat.

Schritt 3: Zugriffsmuster 4 (getDueRemindersByDate
) angehen
Die Anwendung verarbeitet Zahlungserinnerungen für den aktuellen Tag stapelweise. Daher muss die Anwendung in einer anderen Dimension auf die Abonnements zugreifen: Datum statt Konto. Dies ist ein guter Anwendungsfall für einen globalen Sekundärindex (GSI). In diesem Schritt fügen wir den Index hinzuGSI-1
, der den NextReminderDate
als GSI Partitionsschlüssel verwendet. Wir müssen nicht alle Artikel replizieren. Dies GSI ist ein spärlicher Index, und die Belegelemente werden nicht repliziert. Wir müssen auch nicht alle Attribute projizieren – wir müssen nur eine Teilmenge der Attribute einbeziehen. Das folgende Bild zeigt das Schema von GSI-1
und enthält die erforderlichen Informationen, damit die Anwendung die Erinnerungs-E-Mail senden kann.

Schritt 4: Zugriffsmuster 5 (getDuePaymentsByDate
) angehen
Die Anwendung verarbeitet Zahlungserinnerungen für den aktuellen Tag auf dieselbe weise in Stapeln wie Erinnerungen. Wir fügen GSI-2
diesen Schritt hinzu und er verwendet den NextPaymentDate
als GSI Partitionsschlüssel. Wir müssen nicht alle Artikel replizieren. Dies GSI ist ein spärlicher Index, da die Belegelemente nicht repliziert werden. Das folgende Bild zeigt das Schema von GSI-2
.

Schritt 5: Zugriffsmuster 6 (getSubscriptionsByAccount
) und 7 (getReceiptsByAccount
) angehen
Die Anwendung kann alle Abonnements für ein Konto abrufen, indem sie eine Abfrage in der Basistabelle verwendet, die auf die Konto-ID (diePK
) abzielt, und den Bereichsoperator verwendet, um alle Elemente abzurufen, deren SK
Name mit „SUB#“ beginnt. Die Anwendung kann auch dieselbe Abfragestruktur verwenden, um alle Belege abzurufen, indem sie einen Bereichsoperator verwendet, um alle Elemente abzurufen, deren Wert mit „REC#“ SK
beginnt. Dadurch können wir die Zugriffsmuster 6 (getSubscriptionsByAccount
) und 7 (getReceiptsByAccount
) erfüllen. Die Anwendung verwendet diese Zugriffsmuster, damit der Benutzer seine aktuellen Abonnements und seine früheren Einnahmen für die letzten sechs Monate einsehen kann. In diesem Schritt wird das Tabellenschema nicht geändert. Im Folgenden sehen Sie, wie wir nur auf die Abonnementelemente im Zugriffsmuster 6 abzielen (getSubscriptionsByAccount
).

Alle Zugriffsmuster und wie das Schemadesign sie behandelt, sind in der folgenden Tabelle zusammengefasst:
Zugriffsmuster | Basis-table/GSI/LSI | Operation | Partitionsschlüsselwert | Sortierschlüsselwert |
---|---|---|---|---|
createSubscription | Basistabelle | PutItem | ACC#account_id | SUB#<SUBID>#SKU<SKUID> |
createReceipt | Basistabelle | PutItem | ACC#account_id | REC#<RecieptDate>#SKU<SKUID> |
updateSubscription | Basistabelle | UpdateItem | ACC#account_id | SUB#<SUBID>#SKU<SKUID> |
getDueRemindersByDate | GSI-1 | Abfrage | <NextReminderDate> | |
getDuePaymentsByDate | GSI-2 | Abfrage | <NextPaymentDate> | |
getSubscriptionsByKonto | Basistabelle | Query | ACC#account_id | SK beginnt_mit „#“ SUB |
getReceiptsByKonto | Basistabelle | Query | ACC#account_id | SK beginnt_mit „#“ REC |
Endgültiges Schema für wiederkehrende Zahlungen
Dies sind die endgültigen Schemadesigns. Informationen zum Herunterladen dieses Schemadesign als JSON Datei finden Sie unter DynamoDB-Beispiele
Basistabelle

GSI-1

GSI-2

Verwenden Sie No SQL Workbench mit diesem Schemadesign
Sie können dieses endgültige Schema in No SQL Workbench importieren, ein visuelles Tool, das Funktionen für Datenmodellierung, Datenvisualisierung und Abfrageentwicklung für DynamoDB bereitstellt, um Ihr neues Projekt weiter zu untersuchen und zu bearbeiten. Gehen Sie folgendermaßen vor, um zu beginnen:
-
Laden Sie No Workbench herunter. SQL Weitere Informationen finden Sie unter No SQL Workbench für DynamoDB herunterladen.
-
Laden Sie die oben aufgeführte JSON Schemadatei herunter, die bereits im No SQL Workbench-Modellformat vorliegt.
-
Importieren Sie die JSON Schemadatei in No SQL Workbench. Weitere Informationen finden Sie unter Importieren eines vorhandenen Datenmodells.
-
Sobald Sie in NOSQL Workbench importiert haben, können Sie das Datenmodell bearbeiten. Weitere Informationen finden Sie unter Bearbeiten eines vorhandenen Datenmodells.
-
Verwenden Sie die Data Visualizer-Funktion von No SQL Workbench, um Ihr Datenmodell zu visualisieren, Beispieldaten hinzuzufügen oder Beispieldaten aus einer CSV Datei zu importieren.