Modeling many to many with DynamoDb (NoSQL)

Question

im workin on a project where ai need to store USERS , TECHNIQUES and SKILLS . Both TECHNIQUES and SKILLS have a N:M realtion with the USER .

I'm new to NoSQL and cant wrap my head around the idea. The App is going to give the USER the opportunity to add these TECHNIQUES and SKILLS to the USERS . Then I need to build a function that queries TECHNIQUES and SKILLS and finds all users that have the queried TECHNIQUES and SKILLS .

I have followed a Udemy course but I did not get an example that I understood. Here on stackoverflow there are a couple of examples but they were different than my example.

I think i just need to see how an exeprienced NoSQL person would solve this to get me going.

Answer 1

My first thought (I'm just learning DynamoDB myself, so this may be naive) would be a USER table with a compound sort key and global secondary indices:

Create the table with USERS as your partition key, and with TECH and SKILL attributes, and generate a compound TECHSKILL field as your sort key. You can add the TECHSKILL field value in the input resolver (just concat the TECHNIQUE and SKILL with a separator, something like TECHNIQUE#SKILL). This lets you find out if a given USER has a particular TECH or SKILL using query conditions (eg, 'starts-with') on the sort key.

Then add global secondary indices on the TECH and SKILL and the TECH:SKILL fields (so you have three GSI), each with USER as its sort key. Now you can query the TECH GSI to find all USER with a given TECH, or query on SKILL GSI, or even query for all USERs with a given TECH:SKILL combination.

With this multiple-GSI approach you can manage the read/write capacities differently for your different queries.

This wonmight be inefficient (I think) if a USER can have a TECHSKILL combo more than once. For example, suppose the TECHNIQUE is "driver" and the SKILL filed holds drivers license category (TYPE_A, TYPE_C, etc). Now let the USER have a TYPE_A license for part of the year, then she gets a TYPE_C (so, new record), but then the TYPE_C certification lapses and she goes back to a TYPE_A over a different date range and you have a primary key collision, you'll get back a list of tuples rather than just one, and you'll have to handle that. If you don't want to transfer/check/sort the query return (maybe it's a long list!) you might need a different design, maybe something involving start/end dates as part of your sort key for the indices.