Modelado de datos
Aquí es donde DynamoDB más se aleja de SQL. No normalizas en una tabla por entidad — partes de tus patrones de acceso y diseñas claves que los sirvan, a menudo metiendo cada entidad en una sola tabla. Bien hecho, recuperas un padre y sus hijos en un solo Query, sin joins.
Mal hecho, acabas con una tabla que no puedes consultar y una migración que no puedes ejecutar. Así que los compromisos importan, y esta sección es honesta sobre los casos en los que el diseño de tabla única es la decisión equivocada.
Empieza por el diseño de tabla única — todo lo que viene después asume ese modelo mental.
Esboza el esquema antes de construirlo con la
herramienta de diseño de tabla única gratuita —
convierte una lista de patrones de acceso en un plan de PK/SK/GSI. Luego
prueba DynoTable para modelar y explorar estos diseños contra una tabla en
vivo — y para la pregunta ad hoc que tus claves no sirven, su
SQL Workbench ejecuta JOIN, GROUP BY y agregaciones en
el lado del cliente.