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:

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.

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:

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 auf. GitHub

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: