Indie-Resource.com

Well, there are several ways to do that, the first is like you said, creating a coupling table where you bind race ID`s to the class ID`s, this is a logical step and follows the database normalisation standard, however you can also program this in your game itself. Verifying the selected race, and use an array in PHP to check which races to select from the database.

Anyway, the first is the best solution. Create a third table where you bind race ID`s to class IDs. It`s flexible. As far as stats go, you should do the same and normalise the database first. The class which you store in the db should be a boilerplate for the player. Let`s say a knight has a default strength of 10, the sum where the player starts with is 10 strength. Any and all future updates are player driven, so the player stats increase. This way you can also have stats for races, an orc ( logically and physically ) should be stronger then a human. So the base strength of an orc should be higher then the base strength of a human.

A player in your database should start with the base strength of the class and the race. You can be as specific as you want, add a new table where you can add extra modifiers and stats if a player reaches a new level, like increasing strength by 2 every new level, 1 for being human and 1 for being knight. But that`s something that`s not relevant, because that should be test-driven and balanced during playing and testing.

You could check out my database model for harry potter, i believe it has a same database model. Check my blog, it should contain 1 entry where the DB model is explained.

Well, that`s what SQL or actually an RMDB is for. It`s designed to structure your application ( or game in this case ) to behave as you want it to. Normalising your information is the best way to go. Hardcoding it isn`t really an option if you want to include items as well. Races and classes is one thing, since you only have single digit values to work with ( max. 6 races, max. 7 classes ) right? Or something like that anyway. That COULD be hardcoded but doing that for items as well is a definite no-go.

You know what helps? Thinking OO. So for example, you have multiple tables, and they can inherit from one another. So you would have a global Items table, the items table contains the item_id, the name and a stat_id. The stat_id is a foreign key to a table called stats, where you have all the stats for that weapon. So the stats table would have fields like: stat_id, strength, defense, magic etc.

Now, you need to create a new table called: race_item, you only have to add records here for each race, class and item. So the table only requires 3 fields, the race_id, the class_id and the item_id. Now you can check this table to see if a race with a certain class can equip it. it might look troublesome but it will save you a lot of time in the long run.