I have the following two items which I need to store in dynamodb
- Artists
- Songs
The artists have an ID (unique for artists), name and gender. The Songs have an ID (unique for songs), title, genre, artist and rating.
How should I model this in DynamoDB?.
I was thinking about this: ID as primary key and having a sort key which contains artist or song so they are distinguished. Is this a good choice? In examples I find I see more variety in the sort key.
What about the field artist in song items? Should I just point to the ID of the artist?
Update: I have many common access patterns. I can probably solve it by creating some indexes but still I have to choose for a good PK/SK:
get songs based on title
get songs based on rating
get songs based on genre
get songs based on artist
get artist based on rating
get artist based on gender
get artist based on name
Thanks
One thing I found out (the hard way) about NoSQL (DynamoDB) modeling is that you need to know all your access patterns before you model your table. In and RDBMS, it's rather common to model first and optimize indexes later as access patterns change. This is not straightforward in NoSQL modeling (otherwise there would be massive migrations from RDBMS to NoSQL).
Having that said, I will now suggest a simplistic model and I will update my answer as the question is updated with access patterns (i.e. "I need to get all songs for an artist").
Artist:
PK: Artist-<Artist ID>, i.e. Artist-1234
SK: <Name>
Attributes: Gender etc.
Song:
PK: Song-<Song ID>, i.e. Song-5678
SK: <Genre>
Attributes: Genre, Artist ID, Rating
This approach will only allow you to get your entities by using their ID.
While it's common in NoSQL to de-normalize data (i.e. store artist data in song) for easiest/more efficient access, I'd go with storing the artist ID because it allows easier updates and better consistency.