Database time!

I have a lot of things still to implement to get my project up and running (and these are just the ones that are obvious to me right now).

#2 is probably rather a large task to set as a single ticket. This morning I have finally managed to finish watching the video from the only day of School of Code I’ve missed, nearly a month ago, which happened to be the day that covered creating a database with tables, environment files, setting up postgres… basically all the stuff I want to do now. I have been walking through the workshop from that day, and I have not found it easy. At the time I thought SQL was a doddle, but I have forgotten it all in the intervening weeks. And the task ahead is harder than what we did before: I have to design my own database schema, which means revising Entity Relationship Diagrams and how tables work etc, as well as how they’re created in SQL.

I had been thinking of my database in terms of a single table, where the details of a bootcamper - their name and gender (needed to keep the game fun if vocals are present) and a one-time authorization code - would be entered into a record by me, and then the bootcamper would log in and update their record by adding data to the empty fields eg songName, mp3Url etc. I was thinking this would be achieved by a PATCH request under the hood, and that no POST route would be needed, as there would never be new records created after my initial seeding. But as soon as I sat down to draw an ERD, I realised that there really should be two tables - something like this:

One, called bootcampers, will have a record for each bootcamper (whether they are a musician or not). I will enter their name (first name only) and gender. I will let the system generate an ID as a primary key, and a random authentication code which I will distribute by hand (via Slack) to each person. According to this post, the UUID generator built in to postgres is an acceptable way to do this. Once I’ve entered that data, this table should never need to be written to again. But a second table, called songs, can hold the song info that a bootcamper will enter themselves. The id of the bootcamper who is the musician for that song would be a foreign key in this table. I thought about using the url of the mp3 as a primary key, since this will be unique (unless two bootcampers have unwittingly collaborated on the same song), but this post says its better to use integers as primary keys. In fact it says it’s better to use keys that have no meaning other than a row identifier. It also points out that urls for a given resource can change, and as we know, a primary key must never change.

Splitting the data into two tables opens up the possibility of letting one bootcamper submit multiple songs - I went so far as to permit this in my ERD above, with the zero-to-many symbol at the songs end of the link between tables. But on reflection, I don’t think that would make for great gameplay, and I’m not sure how I would prevent dozens of entries by one person. So I think I will change the above to 0 or 1 on the right. If I recall, the way to do this is to specify that the Foreign Key must be unique in songs. A nice thing about this new design is that when a bootcamper submits a song, they will be making a new row in the table, so I can achieve it with a POST request, which feels cleaner and more appropriate than using PATCH.

I guess this design also makes it relatively easy to add a third table of data relating to the playing of the game (eg games played and scores) which could link to the bootcampers table, since they will be the players. Although that’s not currently in scope!