And once you've picked a class, try to find a mentor.
Account Details | |
---|---|
SteamID64 | 76561198014974462 |
SteamID3 | [U:1:54708734] |
SteamID32 | STEAM_0:0:27354367 |
Country | Canada |
Signed Up | October 17, 2012 |
Last Posted | May 4, 2014 at 8:14 AM |
Posts | 103 (0 per day) |
Game Settings | |
---|---|
In-game Sensitivity | i'm very sensitive |
Windows Sensitivity | don't be mean |
Raw Input | 0Â |
DPI |
|
Resolution |
|
Refresh Rate |
Hardware Peripherals | |
---|---|
Mouse | |
Keyboard | |
Mousepad | |
Headphones | |
Monitor |
This whole topic is really interesting. Dunno if anyone follows the NHL much but there's a very similar debate going on there about the merits of advanced stats vs traditional status or the "eye test". A lot of the pros/cons going back and forth are very similar.
I don't think stats are going to tell you everything, but they don't have to do so to be useful. All they have to do is show trends, and give you more information to work with - and if you're open to interpreting, it can be very useful.
"You can’t disagree with the numbers, you can only disagree with the conclusion.” - Stan Bowman
TwitchTVJohnMangachuTwitchTVJohn:(KJP831TwitchTVJohnxE: please find a ringer for mangachu he's not allowed to playCan I have an explanation on why he can't play?
Because he's fun to troll.
mangaJohn
more like mangachooch
i play tf2 on my blackberry and still manage to go at least 11 ham
A great tool for doing database diagrams is Visual Paradigm. It has a free community edition...it's by far the best design/diagram tool I've used. I actually end up doing a lot of ERD's at my work, but it's just my preference to have it diagramed out before I start programming. Also VP let's you generate database scripts from the diagrams. Plus management loves visuals :)
ykpegedeseThe nitty gritty of normalization can get very hairy. Long story short, do it on data that shouldn't be normalized and you will get stuck with all the negatives with very little benefit.
What is the real purpose of this data? A lot of read/write? Analysis? How much data will there be? In the world of DW/BI, you rarely see normalization for a reason(long story short). Normalization trades performance for efficient use of space, read/write operations, etc. If analytics is your primary need, you shouldn't need to carry out normalization so heavily. If you're limited by hardware, you may need to consider going one way or the other even if the data you have and the purpose you need may require otherwise. If your data isn't going to be too big, denormalization isn't going to be too necessary either.
It seems that you will be doing analytics similarly to what BI people do. You should consider making your database similar to that of what you see in a DW and mix in normalization when necessary instead of taking normalization to the extreme. When I worked as a data warehouse consultant, getting this done correctly was one of the key concepts to master. Since you don't have a DW size of Loblaws but also will likely have decent amount of data needed for analytics, you shouldn't need to go with either extremes of normalization/denormalization. Keep in mind though, even databases that should carry out normalization often eventually need to be denormalized for performance reasons. I am now a SDE with specialty in ETL, and RDBMS, and denormalization is one of the things I have to do now because our database is getting too large.
You make good points, but I can't see a TF2 league having such a large amount of data that he'd have to worry about denormalizing for performance reasons..I'd err on the side of storing properly normalized data to begin with and only denormalize if performance problems appear.
LexxThanks for the comments. You're definitely right about the need to have well defined requirements. In my first post on the thread I added a first version of these, based on my current understanding of how a TF2 competition works. I'm not sure if I got everything right, so any corrections/additions would be very helpful.
Good catch on the intersection table between Players and Teams. Perhaps I need a similar junction table between Teams and Matches as well? And if I add a relationship between Divisions and Teams, then I guess the one between Divisions and Matches becomes redundant. I'm not too good at this whole database normalization thing yet. Here's an updated entity-relationship diagram, I hope I understood your comments well. I'm still not sure what to do about the division table/rankings. Is this an association with derived fields? Or does this only appear in the visual reports generated from the application?
I don't think you need an intersection table between teams and matches. A match is limited to two teams, so you can just have both team ids in your match table.
As for the ranking, it only appears in visual reports. You already have all the data, you'd just say get the teams in this division ordered by number of wins. Now, the application might choose to cache that data in a table, but that's not part of your main data storage concern.
Benroadsmansfield7BenroadsI'm not expert by any means and there's a very good chance that my professor has been teaching us an outdated as fuck way of doing these diagrams. Anyway I think rounds would need to be weak to matches as they cannot really exist without a match?Diagrams themselves aren't that important as long as you understand the concepts of normalization.
Yeah I dunno I kinda regret taking this teacher as he does not post anything on blackboard and if you miss class and ask for the handouts/whatever happened in class he gets annoyed. Most likely going to have to retake it since his first test was like 4 pages of SQL syntax (written) and I bombed it.
feel free to dm me if you need any help or anything
BenroadsI'm not expert by any means and there's a very good chance that my professor has been teaching us an outdated as fuck way of doing these diagrams. Anyway I think rounds would need to be weak to matches as they cannot really exist without a match?
Diagrams themselves aren't that important as long as you understand the concepts of normalization.
A division doesn't have a ranking, it has teams. A ranking is displaying teams based on their match results, it's not an entity by itself.
You'd also want an intersection table for player and team, since even if a player is only going to be on one active team at a time you'd want to keep a history, and account for teams going inactive, etc.
I think this is a scenario where you really need fully defined requirements as to what a league is going to be before you start worrying about how to store the data.
here's a better one:
bind v "exit"
downpourdont minus frag me ILL KILL YOU
do you want to get minus fragged? this is how you get minus fragged
defyshiznohttp://i.imgur.com/pj709GI.gif
oh right
that show is atrocious
tf.tv forum heresy detected