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.

0 di 7 lettiQuiz

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.