Results 1 to 11 of 11
  1. #1
    Join Date
    Apr 2011
    Posts
    3

    Database Design Think Tank

    Greetings Everyone,

    Recently I started playing starcraft 2, I joined a clan and thought that a simple database could help but I am fairly inexperienced with the process. I wanted to post here and see if the community could help me to reach my goal. If possible I would like the database to be scalable since it supports multiple games but I wanted to start with one and see how it went.

    I want this database to contain some information regarding members and their gaming preferences/skill levels. I want users to be able to query the database and create a member profile for themselves, which can be edited(unsure about the feasibility).

    Function: Allow Members and/or Organizers to have data available to them to setup (practices/tournaments/competition) based on information about members of my clan


    Brainstorming:

    Entities - Member, Game, Game_Mode, Game_ModeRank, Race


    Fields -

    Member - Handle(PK), Join_Date, Gamer_Type, Platform
    Game - Title(PK), Genre, Platform
    Game_Mode - (Unsure Modes Include 1v1, 2v2, 3v3, 4v4, Coop, and FFA)
    Game_ModeRank - Rank(PK) (Bronze, Silver, Gold, Platinum, Diamond, Master, and Grandmaster)
    Race - (unsure choices include Terran, Zerg, Protoss, and Random or any combination)

    ** for Game_Mode I want users to also mention if they are casual or competitive in each catagory. Would I just make 2 of each or another entity?


    I know that if I want it to work alot of more needs to be done. I will post more as I make changes. Thanks!
    Last edited by jasonk1229; 04-04-11 at 19:47.

  2. #2
    Join Date
    Mar 2003
    Location
    The Bottom of The Barrel
    Posts
    6,102
    This is a slippery slope and can get very complicated, very quickly. I'd say before you start brainstorming about design, nail down the functional requirements you would like the design to handle. You listed a couple... flesh them out and figure out exactly what you'd like to be able to get out of the database, THEN figure out what needs to go in.

    Clan sites can get super complex because there can end up being a metric ton of stats/prefs/relationships/etc that you want to track. I'd say find a niche that actually needs some help to track, figure out exactly how you want to address that niche, and then execute it. Don't let yourself get distracted by more features. It will only end in malice and tears.
    oh yeah... documentation... I have heard of that.

    *** What Do You Want In The MS Access Forum? ***

  3. #3
    Join Date
    Apr 2011
    Posts
    3
    My masterminded main issue for trying this out was to help the people who want to organize matches/tournaments to find the players that want to play competitively. So that would be my niche, ie say I want to plan a tournament that is based on 2v2 teams, Id like to have a database that can return the results and skill levels of the players(in that particular category).

    As far as all those relationship and other metrics thats beyond the scope of what I wanted to do.

  4. #4
    Join Date
    Mar 2003
    Location
    The Bottom of The Barrel
    Posts
    6,102
    How much support do people really need? What do they complain about having to take care of some other way? Is it really finding people to compete with? Stats? Event execution?

    How do you think people will use the platform? Walk through a few "user stories" on what typical usage would look and feel like. Your outline is still pretty loose...
    oh yeah... documentation... I have heard of that.

    *** What Do You Want In The MS Access Forum? ***

  5. #5
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,592
    Quote Originally Posted by Teddy View Post
    This is a slippery slope and can get very complicated, very quickly. I'd say before you start brainstorming about design, nail down the functional requirements you would like the design to handle.
    I take a different path to development. My philosophy is that if you focus on features and requirements when designing your database, then those features and requirements will be all that is supports. When you come to the point that you want to enhance it, you find that your design is woefully inadequate and will require major refactoring or a ton of klunky coding to work around the deficiencies.
    Instead, continue as you are and focus on modeling the components and relationships.

    If you code to features, those features are all you will be able to satisfy.
    If you create an accurate model of your business, then you will be able to satisfy all the requirements of your business.
    If it's not practically useful, then it's practically useless.

    blindman
    www.chess.com: "sqlblindman"
    www.LobsterShot.blogspot.com

  6. #6
    Join Date
    Mar 2003
    Location
    The Bottom of The Barrel
    Posts
    6,102
    What you described in the first paragraph is half assed design. Designing for extensibility is not mutually exclusive from limiting scope creep.

    In this case he's the BA as well as the DBA. Right now he shouldn't be concerning himself with technical details. That's what I'm driving at. How many man hours have you lost over your career due to woefully incomplete or flat out incorrect requirements? How do you avoid that? I'm asking questions in a specific order for a reason... I would not go about trying to develop components and relationships to accurately model my business until I've figured out what my business model is in the first place. It's bad mojo to ask novice devs to start building out a design before they've worked out exactly what it is they're trying to build.
    Last edited by Teddy; 04-05-11 at 12:01.
    oh yeah... documentation... I have heard of that.

    *** What Do You Want In The MS Access Forum? ***

  7. #7
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,592
    I beg to differ. The design methodology I described is 100% Fully Assed.

    Its only drawback would be that it does not give the novice developer as much practice at refactoring as your methodology would, but perhaps he can gain those skills elsewhere (Java coding, for instance....).
    If it's not practically useful, then it's practically useless.

    blindman
    www.chess.com: "sqlblindman"
    www.LobsterShot.blogspot.com

  8. #8
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,592
    Quote Originally Posted by Teddy View Post
    How many man hours have you lost over your career due to woefully incomplete or flat out incorrect requirements?
    Far too many. Which is, again, why I try to focus on modeling the business rather than supporting specific requirements.
    I'm confused. Were you trying to help prove my point?

    Quote Originally Posted by Teddy View Post
    I would not go about trying to develop components and relationships to accurately model my business until I've figured out what my business model is in the first place.
    Wait....did you read my post? What you are describing now seems to be the opposite of
    Quote Originally Posted by Teddy View Post
    ...before you start brainstorming about design, nail down the functional requirements...
    ...figure out exactly what you'd like to be able to get out of the database, THEN figure out what needs to go in...
    If it's not practically useful, then it's practically useless.

    blindman
    www.chess.com: "sqlblindman"
    www.LobsterShot.blogspot.com

  9. #9
    Join Date
    Mar 2003
    Location
    The Bottom of The Barrel
    Posts
    6,102
    I yield. "ready, fire, aim" is a lot more exciting than my approach.
    oh yeah... documentation... I have heard of that.

    *** What Do You Want In The MS Access Forum? ***

  10. #10
    Join Date
    Apr 2011
    Posts
    3
    It is more aimed at leaders/organizers of events to see all the member data laid out in front of them to easily match up against one another. I would like it to be more than that thought I want members to be able to see a list of everyone in the clan for example who will plays sc2.

  11. #11
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,592
    Quote Originally Posted by Teddy View Post
    I yield. "ready, fire, aim" is a lot more exciting than my approach.
    ...which appears to be closer to "aim, fire, ready?"

    Quote Originally Posted by jasonk1229 View Post
    ** for Game_Mode I want users to also mention if they are casual or competitive in each catagory. Would I just make 2 of each or another entity?
    You will have a Member table and a Game_Mode table, and you will need another table (Member_Game_Mode) in which you relate the records from the first two table. This establishes a many-to-many relationship between the two. In this table, you can record their style of play. The natural key for this table will be MemberID|Game_ModeID, unless you want a player to indicate that they participate in both casual and competitive games in a particular category, in which case the natural key would be MemberID|Game_ModeID|Playing_Style.
    If it's not practically useful, then it's practically useless.

    blindman
    www.chess.com: "sqlblindman"
    www.LobsterShot.blogspot.com

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •