Hello.
The explanation about second normal form was a real eye opener. I can't find a way to thank you enough for it
So, about the attributes..
As you said is_guest is redundant. It just means it is a temporary account that will be deleted on session end, and does not have an email.
So I can remove it.
is_online really is not supposed to be in the database, but I am making a page with django and I am not sure if I can
check if there is an ongoing session with a specific user. I will remove it if I can though.
Below is my current idea of the database structure, and the explanation for each of the fields.
It is going to be a wall of text, sorry.
Tables
Table Accounts
name: varchar (PK), Its the username of the account. Maybe I should be using a separate ID for the PK, but since I could enforce unique usernames this way, I figured I'd just make this the PK.
email: varchar, The email. Nullable, and if Null, this account is a "guest" account and gets restricted access to the site.
password: varchar (cyphered before added to DB), The password.
elo: smallint: This is a number that goes up and down depending on the player's win/lose ratio, that represents this player's skill.
I have no way of using this for now, but I will later implement a queue which only matches players with close enough elo.
Because name is the PK, at no point I will get two records when querying by name.
None of the other fields can determine another field.
So this field is in third normal form.
Table Queue_sessions
Since I am making a multiplayer game, I need a way for players to wait in a queue until there are enough players to fill a match lobby with.
This is where currently queued players get recorded.
name(FK): The player that is in queue. Unique, not nullable.
queue_status: tinyint, This is either 0(Not in queue),1(In queue waiting for match),or 2(In queue but not available for matching.)
Reasons for the status may vary, like the user being prompted for confirmation to join a match. It is in queue, but not eligible for receiving another alert for a match.
queue_time: time, The amount of time this player has been in the queue. Players with the bigger queue_time are prioritized to find a match quicker.
Because name is not nullable and always unique, I can also query this table by name and never get 2 different records.
I cannot determine any other fields using anything other than name, so this table must be in third normal form.
Table Game_sessions
My game is a moddable, multiplayer, turn-based game.
Which means anybody can make modified versions of my game by changing the game logic,
There are multiple players interacting with each other in a match,
And I do not need to care about latency.
Because it is moddable, I cannot make a table for each game type, and ensure I only have the fields that I need.
So this is what I've came up with for now..
name(FK): The name of the player in game. Unique, not nullable.
game_info: a varchar that will hold a JSON, not too big in size, that holds all the variables needed for the game.
The field name will likely change. Not nullable.
match(FK): The ID of the match. It refers to the table Matches. Not nullable.
name is unique and not nullable, game_info and match is not unique.
This table is in third normal form.
(And some more fields might be added.)
Table Matches
id(PK): Just an auto-increment int.
ruleset_id(FK): The id of the used Ruleset(Object used to modify the game). Refers to the table Rulesets. Not nullable.
ongoing_time: Time this match has been going for. I might have to terminate matches that go on for too long and delete records related to it. Nullable, because it is null for finished matches.
result: A JSON that holds information about a finished match. Contents vary depending on the Ruleset, so again, I cannot make definite fields to hold the values. Nullable, because it is null for ongoing matches.
I have a PK, no other value is unique, none of the values define anything other than the PK. This table is in third normal form.
Table Rulesets
id(PK): Just an auto-increment int.
content: JSON to be read by the backend code. unique.
No two rulesets will have the same id, or the same content. Always only one record when I query for either of the fields.
This table is in third normal form.
Is this correct?
Thanks.