User Data Model in DynamoDB

Question

In C#, I'm currently using DynamoDB to try and structure my application/platform where I have 3 models on a single document:

1. Company
2. Department
3. Employee

In the example below, I have incorporated those models into a single item which I read is best practice to avoid relational database practices.

However, my question is how I would query my Employees when they log in or register themself? Username is always gonna be unique across the entire platform (no matter company or department)

• I need to find the specific Employee based on Username (to compare login details etc, when logging in)

• I need to know when a new Employee is registering, if an Employee with the same Username already exists or not.

   { "CompanyID": "035129ab-4d60-42b0-8bba-a2f0860ca93c", "CompanyName": "Test Company", "CompanyAddress": "Test Address 22", "Departments": [ { "DepartmentID": "3549aaab-f244-48a5-8e9b-d871357cfb47", "DepartmentName": "Seattle Department", "Employees": [ { "EmployeeID": "61dcdf81-571f-4a70-9020-161719120da6", "EmployeeUsername": "JohnDoe", "EmplyeeEmail": "John@Doe.com", "EmplyeeFullName": "John Doe", "EmployeePassword": "C78AEB71D55B194A1CBE22533823663B" }, { "EmployeeID": "b70e29da-eba7-425a-ab4a-6b96ed479c52", "EmployeeUsername": "FooBar", "EmplyeeEmail": "Foo@Bar.com", "EmplyeeFullName": "Foo Bar", "EmployeePassword": "FF0F0C99A83829F0D24A1B1BDC2E7780" } ] } ] 

  }

Is this the best way to do it? Is there a better way? I would very much appreciate any help! :)

Thanks!

Answer 1

In general, I agree with the concept that storing relational data in NoSQL, a single document approach like this makes sense on the surface. However, when you start digging into it a bit more, you run into quite a few issues.

The first, and the biggest for me, is how easy the data is to query. In your example, you have employee lists spread across multiple documents, nested fairly deeply into the documents. This can make it very difficult (and slow) to query on this information. Many NoSQL solutions provide indexing on child keys, but even this can be complex to configure correctly.

You could obviously adjust the hierarchy of your nesting, and move the Employee data to the root level as you mentioned in your comments. This would make it much easier to query on Employees. However, now you are duplicating data. The duplication is not a major issue because of the extra data, it is mainly a concern of data congruence. What if you need to update the information for a department or company? Do you have to loop through every employee document and update their department as well? Are you splitting IDs between these departments so you know which ones are the same? How do you merge data once you get it out of the database?

For this example, it is absolutely relational data. The best place to store it would be in a relational database. If you are concerned about availability, scalability, etc ... Why not use Amazon RDS and use Amazon Aurora? Sure, the cost is going to be a bit higher to get started than DynamoDB but this is going to be a great long term solution for relational data.

If you are set on using DynamoDB, I would store the data in separate tables. It is going to be the cleanest in the long run. This will mean you need to query multiple tables in some cases, but you should be able to mitigate this using BatchGetItem which according to the documentation:

returns the attributes of one or more items from one or more tables

I hope this insight helps. If you have any questions, please feel free to comment and I will do my best to answer!