I guess that would depend on which DB you’re most comfortable with. I developed for a number of years on relational databases (MySQL, SQL Server, like that), which are table-based: your model usually represents a table, each row of the table represents a record, and each column of the table represent properties of that model. It works, but it isn’t ideal in a lot of situations.
Lately, I’ve been doing quite a bit with Mongo/mongoose, Firebase, and things like that. These are more document-based databases, rather than relational, and often referred to as “NoSQL”. We don’t need to learn a complete query language to use them, and they store data in a format we can handle, usually JSON or something similar.
For your particular case, you may find NoSQL types like Mongo or Firebase work quite well. Rather than needing a “Users” table, a “Events” table, a “Scores” table et cetera ad nauseam, you might have a user document, which represents the User schema, containing all the information about this user: what events she’s participated in, and what scores she has had. The scores property of a NoSQL document might become an Array (or perhaps the ‘events’ property is an array of objects, containing a link to the event id and the user’s score for that event).
NoSQL (like Mongo) is definitely the more flexible option, and depending on the back end you’re basing on, might be a more robust development option.
Of course, if you plan to develop something completely client-side, then Firebase is worth looking into – you’re given an API to communicate with, but all the logic happens on the client system.