I'm trying to design an database using Laravel's relationships for a sports site. So far I've got 8 tables planned:
Organization
League
Season
Teams
Roster
Games
Players
Stats
Each Team belongs to and Organization and a League. Organizations and Leagues has many teams. This is because Organizations can have teams in different leagues.
After that I'm starting to run into questions. My plan is that the Games table will store Home and Away teams, so I think that's a has many relationship. Games also need to be part of a season and league so Games would belong to Season and League. Am I on track there?
Also, Players can belong to more then one Team during the same Season. That's why I did the Roster table do that Players can be linked with Teams and Seasons there. Plus I'm hoping that would be historical rosters by Season. I can't wrap my head around what relationships I need to pull this off.
Last would be Stats which would belongTo Games and Players and each player would have their own Stat row for each game played. Or would have be a has Many relationship?
For Games, you can simply have a home_team_id and an away_team_id foreign key column to the Teams table; this would be two belongsTo relationships for Game and one hasMany relationship for Team.
As for Rosters, it sounds like a simple pivot table and a belongsToMany relationship between Players and Teams. Rosters would have: player_id, team_id, and season_id. For Player, Roster, and Team, you could have a maximum of two belongsToMany relationships each.
Related
I am developing a database for my wife's business so she can track her Cost of Goods and although I am familiar with SQL I not had to design a database in many years so I am looking for some design feedback. My structure is as follows:
Tables
Suppliers
This is who we buy the product from.
Events
One supplier can have many events (estate sale, etc). The Foreign Key Events.SupplierID points to the Primary key in the suppliers table.
Products
One Event can have many products. Each product is unique. The FK products.EventID points to the PK Events.ID.
SalesRecords
Each product can only be sold once since each product is unique. This table keeps all of the information about the sale, related fees, etc so we can calculate profit. A record is only generated here when a product is sold. The FK SalesRecords.ProductID points to the PK Products.ID.
I am creating a website for my buddies and I to track all of our offensive softball stats. I am getting tired of maintaining a huge excel spreadsheet and emailing it out every week, so a website is the way to go.
I've created the DB a few times but I want to make sure I am making this thing right without duplicating data. Here is what I have for models:
Person - Main person object/ (Id, FirstName, Lastname, NickName, email, etc..)
Player - Inherits from person. Players play games for teams. (Id)
Manager - Inherits from Person. Team has 1 Manager. (Id)
Team - Team in a League. Has 1 manager and many players. (Id, Name, Weeknight, Year)
Weeknight - enum. Sunday-Saturday. A Team plays on 1 weeknight
League - A Team plays in 1 league. (Id, Name)
Game - A Team, Many Players (Id, Opponent, Date, Score, result)
Result - emum. Win or Loss for A Game
Stats - hard part. Need Game stats for Team and individual player.
The 1-1 relationships aren't an issue, it's relating players to a team and a game and linking the stats that's hanging me up. If anyone has any advice or better, a schema drawing, that would be awesome.
Thanks!
Is it acceptable database design to have two different relations between two table.
For instance, the user can create a product and buy the product.
So there will be relation between the user and the product one to many where the product table has the UserId, while when the user buys a product it is a many to many relation which is created by joint table that has UserId and ProductId that represents the order.
It is a good design or there is another way of doing that ?
I'm building a game system and I'm designing a database for this which keeps track of the games that players have played. Here are the entities in my system:
1.Players 2.Groups 3.Games
Each player can belong to multiple groups and a group will have multiple players in it.
Games will be played in the context of group by the players in that group. So each game will have a group that it is being played in and the players who are involved in that game.
In addition to players personal stats, each player will have stats specific in the context of their group. What tables do I need for this system.?
Here is what I have thought of so far, I will have a players table. Each player with a unique id and rest of his information, along with his stats combined across all of his groups. There will be a group table, with group id, group name and other information about group.
I don't know how to represent players to group relationship. Also I'm not clear on how the game table would look like. I'd assume each game has a unique id, players playing it and the group id in which that game belongs to.
yes you need relation or associative tables...
something like
player_group
---------------
player_id
group_id
game_player
-------------
player_id
game_id
in the game table:
game
----------
game_id
group_id
I am new to couchdb.Now I am working on a couchdb project in my university.My project is football schema,where I have to prepare documents for players and clubs.I have already created individual documents for players and clubs in couchdb.but I dont know how to relate the players documents to the clubs documents.I mean which player belongs to which club...
You can store a list of doc IDs of players in each club document and/or the doc ID of the club of the player in each player document.
Then you can use views and lists to find all players in a team for instance.
Note that it is your responsibility to keep the database consistent (that is to remove the doc ID of a player from its club when you remove the player from the DB for instance).