1 Replies - 3646 Views - Last Post: 02 February 2012 - 02:24 PM Rate Topic: -----

#1 kevin_mchugh  Icon User is offline

  • D.I.C Head

Reputation: 11
  • View blog
  • Posts: 64
  • Joined: 08-April 09

Database Design Help

Posted 22 January 2012 - 07:52 AM

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

Is This A Good Question/Topic? 0
  • +

Replies To: Database Design Help

#2 e_i_pi  Icon User is offline

  • = -1
  • member icon

Reputation: 782
  • View blog
  • Posts: 1,663
  • Joined: 30-January 09

Re: Database Design Help

Posted 02 February 2012 - 02:24 PM

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.
Was This Post Helpful? 1
  • +
  • -

Page 1 of 1