Save match results

Hi there!
I want to save match results in the database but I have a couple of doubts and I’m no really sure what is best course of action.

A naive option could be to have a storage record with all the match results for each user but this probably grow large and become unmanageable, so it will be preferable to have a record per match result.
The question is. Should I create a new database table in the schema? Is there anyway to have multiple entries for one user?

Thanks in advance,
Kind regards

You should use Nakama’s storage collections feature. It can store multiple objects per user and allows ordered listing operations.

That said I would probably use a single object and just trim the match history when it grows past a certain point. Probably an object with a list of match results - when you find you’re adding an 11th item to the list just cut out the oldest one at the same time, that will keep the list to no more than 10 or whatever number you need. An infinite match history is usually a bad idea, just like any other unbounded data set.

As long as the objects belong to a diferent collection or key right?
For example, if I write something like this:

local user_id = "4ec4f126-3f9d-11e7-84ef-b7c182b36521" -- Some user ID.
local new_objects = {
  {collection = "matches", key = "pending", user_id = user_id, value = { ... }}, -- some value 1
  {collection = "matches", key = "pending", user_id = user_id, value = { ... }} -- some value 2
}
nk.storage_write(new_objects)

The entry for the pending match will be only one and will have the value of the second write.
Am I wrong? Sorry if it sounds too basic, I just want to be sure about what I can do and what not

Kind regards

Yes, the collection+key+user_id tuple is what determines the identity of the storage object. In your example you’re only effectively writing one object.

In your case you can have a collection called “matches” and keys that are the match ID. As I said though I would be careful about allowing this to grow indefinitely, you can end up with a large amount of unused data being stored for longer than it should be.