1 or 2 tables dilemma

[Chris]

When we make items there are always 2 tables. Definition (per item type, holds name and stats) and data (per player, holds ownership, slot, status, quantity). Obvious and simple.

I have a similar thing called "office" (given to players by the team leader). But each player can have only up to 3 offices max, and average will be like 1-2 per player (so much fewer than items). It would be also much more frequently queried for name compared to items, since all players want to know what offices you hold (as opposed to items that are usually private).

So, should I make traditional 2 separate tables or just dump it all in 1 and save joins, make it simplier and save one table query?

[Mutant]

My personal opinion (and I know some people here disagree) is to design it 'correctly' first, so use 2 tables if that's the natural fit for this data (i.e. it's normalised). There's a good chance the extra joins won't actually matter... most DBs these days are pretty damn fast at joining, so long as you get the indexing right.

If it turns out it's not fast enough, then you can consider ways to optimise it. Denormalisation is only one option here. There's also caching, query tuning, etc.