[kevin_mchugh]

Hello All,

As the title says I have a couple of questions about Database Design. I am trying to write a Wrestling Management Simulation (As a bit of fun and to better understand VB.NET) and I am trying to implement my underpinning database structure. The problem comes with Tag Teams. (Two man wrestling team.)

Firstly, I have an abstract class in the system which contains certain properties which are inherited by the various different types of SINGLE performers. But these attributes would equally apply to a Tag Team. A tag team is comprised of two single Talent instances. Now should I create another version of these properties for the Tag Team table or just inherit anyway?

Secondly the Join. between the single talents and the Tag Team itself. I already have a "Faction" table which is simply a group of individuals who fight under a single banner but aren't a "team" as such. This has a "memberOf" join to connect the talent to the faction. My question is SHOULD I use the same table to connect the Talent to the Tag team? I cant see what hard it would do....but then again.

I know the obvious thing here but Tag Teams and Factions are different things and will work differently in the game. I understand that a lot of this is personal choice but I was just looking to avoid headaches in the future.

Thanks for any advice, and if you need me to translate or explain any of the wrestling nerd jargon above just give me a shout. Shout especially if I am not making any sense at all.

Thanks again.

Kevin

[e_i_pi]

I'd use a Team table and a bridging table, like so:

Team
ID (PK)
Name
FormationDate
--any other attributes--

TeamMembers
ID (PK)
TeamID (FK -> Team.ID)
WrestlerID (FK ->Wrestler.ID)

This ensures normalisation, and allows extensibility of teams in unforeseen cases.