He trabajado mucho con bases de datos relacionales y un poco con bases de datos NoSQL (solo para que sepa de dónde vengo). En mi humilde opinión, las bases de datos NoSQL se adaptan mejor a escenarios en los que uno o más son ciertos:
- Los datos son esencialmente planos (sin muchas relaciones, casi como un archivo plano antiguo)
- Hay un registro de tipo "principal" definido con registros "secundarios" que son lo suficientemente pequeños/a los que se accede con la suficiente frecuencia con el padre como para justificar su integración en el registro.
- Necesita la libertad de agregar/rellenar campos dentro de lo razonable. Me gusta pensar en ello como una herencia, donde cada elemento de la tabla comparte algunas características comunes (ID, nombre), pero diferentes registros pueden tener características diferentes. Por ejemplo, un catálogo de productos en línea puede contener libros, bicicletas y canciones en MP3. Un registro para un elemento de "libro" tendría cosas como ISBN, número de páginas, autor, etc. Una "bicicleta" podría tener tamaño de rueda y color, y un "MP3" tendría longitud, artista, género, etc. Nunca obtendría todas esas cosas en una tabla de "elementos" en un RDS sin una sobrecarga seria o sin dejar los campos vacíos. La base de datos ANoSQL le permitiría almacenar toda esa información en la tabla, y solo para los elementos que la necesitan.
Definitivamente puede crear el esquema que incluye con su pregunta usando las capacidades de indexación de Dynamo, pero estaría tratando de hacer que una base de datos NoSQL actúe como un RDS.
Dicho esto:yo mismo lo probaría primero con Dynamo como una experiencia de aprendizaje. :)
