Relational database

Runtime Framework
1

Hi!

Im doing some heavy wiring to work with nakamas database, and it works. But I do struggle to understand how to structure some things when it comes to the storage engine.

The image below demonstrates how i store data of a character on an account. One account can have many characters so each is identified with a unique id as shown in the image below.

image
image2528×534 74.4 KB

Now I want to create a guild system in the game.
My approach to this would be to store an object like so:

type GuildApiModel sturct {
     Id string
     Name string
     Members []string
}

This object would then be stored in the engine as such:

Collection.     Key.             User.    
id_of_guild.    guild_info.      server_id

from that table i can fetch the guild and its members (ids).

The problem is, when the player is logging in, he needs to get the data from the guild he has joined. If i use this approach, i need to fetch all the guild records from the storage and iterate over all the members to find his guild and add that to the response. This doesn’t feel this is the right approach.

Im very used to work with coupling tables (mysql) where we can use foreign keys to get the correct data. How am i suppose to think and approach cases like this?

I could also store the guild id in players metadata to get fast access to the guild record. This is probably what I would do, but then i need to manage data on 2 records all the time. If the player leaves the guild, remove him from the guild data and the players meta data etc… still doens’t feel right.

Best regards,
/g

2

Hello @gruset

Is your specific need not covered by the Group APIs?

3

Unfortunately not. I need a bit more control in my game then using that. Its also account based, while i need character based.

This question is also a more general question how to couple things together in the storage engine

4

I see, I think the approach you describe is okay, but it would make more sense to have guild_ids under Collection and the <guild_id> under the key, this way you can use the storage engine listing API to list all guilds.

To not having to list all guilds every time you want to check membership, the easiest is to keep a record per user where you keep track of the guild id (or ids) he’s a member of.

If you structure this as:

Collection.           Key.             User.    
guild_memberships     guild(s)         <user_id>

and store the guild_id in the value then you can quickly check if a user is the member of a guild (or multiple).