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

Single-table design in DynamoDB

Single-table design in DynamoDB — perché una tabella con chiavi sovraccaricate batte una tabella per entità, con un esempio concreto ordine/cliente e il pattern di overloading dei GSI.

Intermedio4 min di lettura

Come modellare i dati in DynamoDB

Come modellare i dati in DynamoDB con l'approccio access-pattern-first — una guida passo passo che trasforma le query di una classifica multiplayer in partition e sort key.

Intermedio8 min di lettura

Quando NON Usare il Single-Table Design in DynamoDB

Quando NON usare il single-table design in DynamoDB — i carichi di lavoro dove più tabelle vincono (analytics pesanti, CRUD semplice, scaling indipendente), con esempi concreti.

Intermedio6 min di lettura

L'attributo Type in DynamoDB

L'attributo Type in DynamoDB — perché marchi ogni item con un tipo di entità per identificare le righe, filtrare un GSI su una sola entità e sopravvivere alle migrazioni future.