Question

I have a table called games (unique by an int).

I have a table called members (unique by username).

In each game, a maximum of 6 members can be involved at one time.

However, a member can resign from a game – BUT I still need to keep a record they had been involved in that game.

I need to do the following separate searches:

1. Active games for a member.

2. Resigned games for a member.

3. Searches in games for an empty slot (ie a place not filled by a member).

What would be the best table structure for this?
Should I put a text field in for a member with a list of all resigned games separated by a comma? (A problem I can see with this is I will ultimately need the games information for these games, so I will subsequently need to do a separate search on the games table for each of these game numbers. That seems really slow work for the server.)

In games, should I have 6 text fields, eg SLOT1, SLOT2 etc with the present player’s username? But again, what about resigned members?

NOW THE MAIN PART OF MY QUESTION (which caused all the confusion above):

How would I set up my indexes on my tables?

When I am doing searches, I will be looking in games looking at the SLOTS1, etc to see if there are any matches with a player’s username. So this is an 6 times ORed search. What do I do to optimise the indexes on the database for these actions?

Then depending on how I do the resigned members for each game, how do I do an index then?

Answer 1

Use a cross-reference table. This is a table with three columns, game (a foreign key to table games), user (a foreign key to table users), and player_number (a nullable integer between 1 and 6, to indicate which “seat” is occupied by the player; null indicates that the player resigned). (Variations are possible on this depending on exactly how your game works and how you want stuff to fit together, but the main thing is that you have foreign keys to games and users.)

The primary key in the above suggestion would be (game, user, player_number) or (user, game, player_number) at your convenience.

It is much easier (both for you and for your database) to search a cross-reference table like this than it is to do a query that involves ORing across six columns.

It is probably a good idea to switch to an integer primary key for the users table, as suggested by @Jermin Bazazian.