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.

0 de 7 leídasCuestionario

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.