I am developing a database for a Fantasy Cricket league for my Database module in college.
I had done the design and was fairly confident that I had a working version, but I suddenly realised that I hadn't handled the swapping of players.
This is a snippet of my diagram since the final version i have is still on paper.
I had this sudden realisation that the total points for an owners squad would be calculated based on the points of the players in the current squad, whether those players had been there all along or not.
How do I maintain the historic data of all the players in a specific squad and their points while they were in that squad?
I'm not sure I'm very clear here.. But would really appreciate the help.
One option is to insert a join table between player and squad, that maps a player to a squad for inerval of time. This way you can select all the players from a given squad for given time interval. Having the players, it should be easy to access the match information, since it is directly connected with a player.
Related
I go to a lot of sports games, mostly hockey. I have been tracking the games via an excel sheet and even at one point a simple database table. I am trying to build this a little better and eventually create a web interface. But I also want to be able to run various queries.
I don't care about player goals, ice-time, sog or any of those stats - merely just teams playing, score and date with a section for notes. (eg, Hat trick, 500th game for player)
So what I had was:
(id, home_team, home_score, away_team, away_score, jersey = [home,away,alt], date, notes, timestamp)
I have thought of other ways to normalize it but I don't want to over complicate it and trying to query has been a nightmare.
I had a three table design in mind:
Team
(team_id, city, state, nickname)
League
(league_id, league_name, conference, division)
Venue
(venue_id, venue_name, venue_city, venue_state, venue_zip, venue_address, venue_capacity)
Venue table and even league table seem unnecessary for the most part but I was thinking of different types of queries.
Then I would create some views or a games table that would pull in the necessary fields.
Queries I had in mind to execute:
Games attended that the home team won
How many times my team has played whatever team and overall record
Games won/lost wearing alternate jersey, home jersey, away jersey
Venues visited and record when visiting
Games attended where there has been a significant event. (Hat trick, record)
Overall record of games attended in x year, all time.
Playoff game record, preseason game record, regular season record (I was thinking I could notate game type in notes or create a field for type and do (playoff, preseason, regular)
Any advice would be appreciated, its not that I do not know how to build the database, it is that I do not know how to build it right and without stressing over the entire website I want to build from it.
Eventually I would like to expand it to other sporting events (football, baseball, basketball, etc..) but before getting too far ahead of myself I would like to get the hockey one running.
Thanks in advance
I have a business case I have not been able to solve yet. Actually I'm stuck with it lot.
I have huge organization with pretty vertical hierarchy.
As average people have 2 team members in their team and there is around 100+ levels from root to bottom (growing constantly). Yet, some members have more than 2 teams and also many have only one team.
I can collect data in 2 steps:
1. When user logs in I get their login information and only then I know he/she exists.
2. As bosses can see their team and their team-team-...-team members salaries and pays I only collect information who is your boss (parent) from each user (authorizing that boss to see your salary and pays). The users don't sometimes know who their direct boss is :) and they see other users in alphabetical order so no sorting by position (at this point).
So giving all that I get random updates to one table with ties between user and one of the users boss. It can but doesn't always (mostly) have to be direct boss of the user.
I can get pretty late updates to very high position in the hierarchy in frequent bases.
It is OK to update TREE periodically not on the fly every time I have collected piece of information regarding bosses.
I have given this a thought for 3 days and nights in the row and cannot figure out ideal and not very expensive (for DB) result yet. I'm sure you have good solution for that problem.
At this point I have MySQL but I'm willing to change.
Novice relational database design question here. This is a "I feel like I'm doing wrong. What is it?" question. What it boils down to is, how can I avoid unnecessary complexity when designing a relational database. I also realise that this is as much a question about class structure design, seeing as I'm using an ORM and I'm really thinking of these tables as objects.
Background
Lets say I want to record the results of a number of competitive games between an unspecified number of "players". These players all belong to a "leaderboard", so, the leaderboard has multiple players and records multiple results. The "score" for each of the players is recorded at the end of each game and belongs to a single "result" instance (see image). A score is also parented by the player to which it belongs.
edit: An example
Each row in the leaderboard table represents a collection of players who together form a league. For example, all of
the players who belong to a tennis league will have the same
leaderboard_id in the player table.
A row in the results table
represents a match that has taken place between players that belong to
a particular league. So the leaderboard_id associated with our
players is recorded in each result in this league. The results table
doesn't hold the score of each player, rather, I've attempted to
normalise (appologies for potentially inappropriate use of that term)
these into a score table.
Bringing this all together. We have a
league in the Leaderboard table, in which a game has taken places
between two players. These players belong to the league in
question. The two players have just played a match and their scores
are recorded as rows in the score table. These rows are collected
together under a single results_id, refereing to a row in the
results table.
Question
Q1. Does this make sense? Is there anything glaringly obvious that is wrong with this design?
As is, I can easily query the scores a particular player has accumulated over time, look up the players that played in a particular result, etc. However, there are some actions that really feel like they should be simple, but, to me, feel overly complicated.
For instance, if I want to return the most recent results for a particular player (ie not the player's scores, rather the results that contain a score that belongs to our player).
So, hand-wavey Q2. Maybe this is just lack of experience with SQL, but, I shouldn't have to do a JOIN to look up this, should I? But then, what's the alternative? Should I create a one-to-many composition between player and results, so that I can simply look up a player results?
With the current design to find the most recent result for a player I would need to do something like this (python sqlalchemy)
Score.query.join(Result, Player)\
.filter(Player.id ==player_id)\
.order_by(Result.timestamp.desc()).first()
Is this bad?
I'm trying to figure out the best way to manage this data storage problem....
I have a table of players, teams, and competitions.
A team may be involved in let's say 3 competitions.
A player belongs to a team, but may only be eligible to play in 2 of the 3 competitions that his or her team plays in. Likewise another player of the same team may be eligible for all 3.
I don't want to add a column to the player table for each competition as I'm then moving away from the relational model. Do I need another table 'competition_eligiblity' - this seems like a lot of work though!
Any suggestions?
Thanks,
Alan.
Yes, you do need a table for competition eligibility.
It really is no more work to put it there. Actually, it will be less work:
Adding a new competition in the future will be a real pain if it involves adding a new column to a table.
If the competition eligibility is stored in columns, performing a query to get information on eligibility becomes a nightmare.
Suppose you wanted to list all the competitions players are eligible for. Here would be your query:
select player, "competition1" from players where competition1_eligible = 1
union all
select player, "competition2" from players where competition2_eligible = 1
union all
select player, "competition3" from players where competition3_eligible = 1
union all
select player, "competition4" from players where competition4_eligible = 1
Sounds like fun, eh? Whereas, if you have an eligibility table, this information will be very simple to get.
Update: storing all the eligibility info in a single value would be even more of a nightmare, because imagine trying to extract that information back out of the string. That is beyond the limits of a sane SQL query.
Creating a new table is really a trivial piece of work, and you only have to do that once. Everything after that will be much easier if you do it that way.
Consider the following tables: Season, Club, Team and Player
A team belongs to a club and has players, but each season the teams of a club and there players can change. I want to be able to follow all changes to the clubs/teams/players per season.
For the moment I create relationship tables like this:
season_club (season_id, club_id)
season_team_player (season_id, team_id, player_id)
A Team directly belongs to a club (has a foreign key column for this).
Is this the best way to go about this or is it better to create a new club for each season and store the season directly in club? I am trying like this because the club data doesn't change between season's and I want to track a club's changes of teams/players and also track the individual players their team changes.
I hope my question is somewhat clear...
Thanks in advance!
For the moment I create relationship tables like this:
season_club (season_id, club_id)
season_team_player (season_id, team_id, player_id)
A Team directly belongs to a club (has a foreign key column for this).
The second of these tables makes a lot of sense to me: together with your four main tables, this should provide all the information you require: you know which players played in which team in which season. And you can even see which teames had any players at all in a given season, from that conclude which teams existed in that season, and from the key on the club conclude which clubs where active in that season. So I don't see any need for the first table, unless your second table is incomplete, i.e. there were clubs for which you don't have data on existing teams, or for which you don't know the individual players.
In terms of performance, more redundancy might be desirable, but in terms of elegance, the above scheme, together with a bunch of nice views, should serve your needs just well.
Is this the best way to go about this or is it better to create a new club for each season and store the season directly in club?
I'd suggest not to do this unless you want to track changes to the club data itself, e.g. a change in address or whatever. If you can identify the same club in different seasons without having to compare names of clubs, I'd consider this a great advantage.