Amazon Dynamo Table Schema

Question

I have been trying to create a Schema for my Android application in Amazon Dynamo DB. I have very less experience with NoSQL Databases.

I have created a Survey based Android Application, now I have certain tables to store in Amazon Dynamo DB.

The Tables are Employees table, Survey table, Question table and the Response table.

The Employees table stores the information for all the employees, the survey table holds the name of the surveys and the employees, who has taken the survey.

My Issue is with the Question table and the Response table. The Questions are dynamic and are based on the employees who is taking the survey.

The answers in the Answer table depends on the number of Questions asked in the survey.

I want to know what should be my @DynamoDBHashKey, @DynamoDBIndexHashKey, @DynamoDBIndexRangeKey in the Question and the Response table, so that I can map question to respones and what should be the @DynamoDBAttribute in both the tables.

The Use Case can be: An Employee of the company posted 12 questions for all the other employees of the company.

Image was taken earlier, later on I added survey table as well

Answer 1

DynamoDB is good at some things and bad at others. Its great at scaling massively and horizontally while maintaining low read/write latency, but introduces eventual consistency, and forces you to make major schema decisions up front, such as what should be in a table, and how should data be partitioned, and what should be the indexes. It demands that you adopt its horizontal scaling model by partitioning your tables into pieces via the partition key.

From the way you have phrased the question it is clear that you are more comfortable in a relational database. DynamoDB is not a great place to start learning about NoSQL schema(less) design - I would have found it quite unforgiving if it was my first NoSQL database, especially trying to model a domain such as the one you describe. Its simply not a great domain modelling environment full stop - its all about horizontal scaling and performance.

If you are more comfortable in a relational database, then use a relational database. If you want to try NoSQL it is necessary to adopt a different mindset when it comes to modelling your domain into persist-able entities. For example, you might include closely related child objects within the schema of a parent record - in your example you might include Questions as children of a Survey and store them in one record, unlike in relational modelling where you would put these in separate tables.