Modellazione dei dati
È qui che DynamoDB diverge più nettamente da SQL. Non normalizzi in una
tabella per entità — parti dai tuoi access pattern e progetti chiavi che li
servano, spesso impacchettando ogni entità in un'unica tabella. Fatto bene, recuperi un
genitore e i suoi figli con una sola Query, senza join.
Fatto male, ti ritrovi con una tabella che non puoi interrogare e una migrazione che non puoi eseguire. Quindi i compromessi contano, e questa sezione è onesta sui casi in cui il single-table design è la scelta sbagliata.
Inizia dal single-table design — tutto ciò che viene dopo dà per scontato quel modello mentale.
Abbozza lo schema prima di costruirlo con lo strumento gratuito di
Single-Table Design — trasforma una
lista di pattern di accesso in un piano PK/SK/GSI. Poi
prova DynoTable per modellare ed esplorare questi layout su una
tabella reale — e per la domanda ad-hoc a cui le tue chiavi non rispondono, il
suo SQL Workbench esegue JOIN, GROUP BY e
aggregazioni lato client.