Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Progettazione dello schema dei pagamenti ricorrenti in DynamoDB

Caso d'uso aziendale dei pagamenti ricorrenti

Questo caso d'uso parla dell'utilizzo di DynamoDB per implementare un sistema di pagamenti ricorrenti. Il modello di dati ha le seguenti entità: account, sottoscrizioni e ricevute. Le specifiche del nostro caso d'uso includono quanto segue:

Diagramma delle relazioni tra le entità dei pagamenti ricorrenti

Questo è il diagramma delle relazioni tra entità (ERD) che useremo per la progettazione dello schema di gestione dei pagamenti ricorrenti.

Schemi di accesso ai sistemi di pagamento ricorrenti

Questi sono i modelli di accesso che creeremo per la progettazione dello schema del sistema di pagamenti ricorrenti.

Progettazione dello schema dei pagamenti ricorrenti

I nomi generici PK e SK vengono utilizzati per gli attributi chiave per consentire la memorizzazione di diversi tipi di entità nella stessa tabella, ad esempio le entità account, sottoscrizione e ricevuta. L'utente crea innanzitutto un abbonamento, in cui accetta di pagare un importo lo stesso giorno di ogni mese in cambio di un prodotto. Possono scegliere in quale giorno del mese elaborare il pagamento. C'è anche un promemoria che verrà inviato prima dell'elaborazione del pagamento. L'applicazione funziona con due processi batch eseguiti ogni giorno: un processo batch invia i promemoria con scadenza quel giorno e l'altro processo batch elabora i pagamenti in scadenza quel giorno.

Fase 1: Gestire il modello di accesso 1 (createSubscription)

Il modello di accesso 1 (createSubscription) viene utilizzato per creare inizialmente l'abbonamento e vengono impostati i dettagli, tra cui SKU, NextPaymentDate, NextReminderDate e PaymentDetails. Questo passaggio mostra lo stato della tabella per un solo account con un abbonamento. Nella collezione di articoli possono esserci più abbonamenti, quindi questa è una relazione. one-to-many

Fase 2: Gestire i modelli di accesso 2 (createReceipt) e 3 (updateSubscription) 

Il modello di accesso 2 (createReceipt) viene utilizzato per creare l'articolo della ricevuta. Dopo l'elaborazione del pagamento ogni mese, il processore di pagamento riscriverà una ricevuta nella tabella di base. Potrebbero esserci più ricevute nella collezione di articoli, quindi questa è una one-to-many relazione. Il processore di pagamento aggiornerà anche l'elemento di abbonamento (Modello di accesso 3 (updateSubscription)) da aggiornare per NextReminderDateo il NextPaymentDate per il prossimo mese.

Fase 3: Gestire il modello di accesso 4 (getDueRemindersByDate)

L'applicazione elabora i promemoria per il pagamento in batch per il giorno corrente. Pertanto l'applicazione deve accedere agli abbonamenti su una dimensione diversa: data anziché account. Questo è un buon caso d'uso per l’indice secondario globale (GSI). In questo passaggio aggiungiamo l'indice GSI-1, che utilizza NextReminderDate come chiave di partizione GSI. Non è necessario replicare tutti gli articoli. Questo GSI è un indice sparso e gli articoli delle ricevute non vengono replicati. Inoltre, non è necessario proiettare tutti gli attributi: è sufficiente includere un sottoinsieme degli attributi. L'immagine sotto mostra lo schema di GSI-1 e fornisce le informazioni necessarie all'applicazione per inviare l'e-mail di promemoria.

Fase 4: Gestire il modello di accesso 5 (getDuePaymentsByDate)

L'applicazione elabora i pagamenti in batch per il giorno corrente nello stesso modo in cui elabora  promemoria. In questo passaggio aggiungiamo GSI-2, che utilizza NextPaymentDate come chiave di partizione GSI. Non è necessario replicare tutti gli articoli. Questo GSI è un indice sparso e gli articoli delle ricevute non vengono replicati. L'immagine sotto mostra lo schema di GSI-2.

Fase 5: Gestire i modelli di accesso 6 (getSubscriptionsByAccount) e 7 (getReceiptsByAccount) 

L'applicazione può recuperare tutti gli abbonamenti per un account utilizzando una query nella tabella di base destinata all'identificatore dell'account (PK) e utilizza l'operatore di intervallo per ottenere tutti gli articoli in cui SK inizia con “SUB#”. L'applicazione può anche utilizzare la stessa struttura di query per recuperare tutte le ricevute utilizzando un operatore di intervallo per ottenere tutti gli articoli in cui SK inizia con “REC#”. Questo ci consente di soddisfare i modelli di accesso 6 (getSubscriptionsByAccount) e 7 (getReceiptsByAccount). L'applicazione utilizza questi modelli di accesso in modo che l'utente possa vedere i propri abbonamenti attuali e le ricevute passate degli ultimi sei mesi. Non vi è alcuna modifica allo schema della tabella in questo passaggio e possiamo vedere di seguito come indirizziamo solo gli elementi dell'abbonamento nel modello di accesso 6 (getSubscriptionsByAccount).

Tutti i modelli di accesso e il modo in cui la progettazione dello schema li affronta sono riassunti nella tabella seguente:

Schema finale dei pagamenti ricorrenti

Di seguito sono riportate le progettazioni dello schema finale. Per scaricare questo schema come file JSON, consulta Esempi di DynamoDB su. GitHub

Tabella di base

GSI-1

GSI-2

Utilizzo di NoSQL Workbench con questa progettazione dello schema

Puoi importare questo schema finale in NoSQL Workbench, uno strumento visivo che fornisce funzionalità di modellazione dei dati, visualizzazione dei dati e sviluppo di query per DynamoDB, per esplorare e modificare ulteriormente il tuo nuovo progetto. Per iniziare, segui queste fasi: