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
Related
I am programming an application and I need to do a database to store the data. The information is similar to the next simple example:
There are multiple restaurants and each restaurant has to send their food to the clients.
The database should be something like:
Restaurant | Food | Where to carry | Who carries
There are multiple restaurants (A, B, C, D...), the food is the same in all the restaurants (hamburgers, fish and salads), the people who carries the food could be working in all the restaurants, and the same house could be asking for food to diferent restaurants. All the information should be stored in a database.
In this case, I want to do a database at least in third normal form. Is it a good practice to make a single database and store all the data in this specific case?
I informed a lot but don't know if I'm doing it the right way because in this case the same information is repeated multiple times like Restaurant X food Y.
Thank you in advance!
The best way is to design it like this:
Restaurant table with the restaurant details i.e. id, name, address etc.
Food table with the food details i.e food name, food id, food price etc
Another table, which may be named as Orders, where you have the restaurant id, order id, house address from which the order was placed.
OrderFood table which contains the order id and food id where both are foreign keys and both combine to form the primary key.
And it is not a good practice to store everything in one table which increases redundancy. Hope this helps.
I am creating a sports collection database of different sports and i am confused of some sort on what tables and primary keys/foreign key combo to use the requirement is as follows:
Should be in a 3rd Normal Form or at least in 3NF.
Here is the Full Description on what I want to do:
Design a database for a sports collection of cards.
You only purchase cards with current market value( at the time of purchase) that are at least $100.00. Your collection about 1000 cards
You collect all kinds of sports cards, from football, basketball, hockey and etc
These cards you collect are produced by different vendors such as ?Topps, Upper Deck, Leaf and Panini.
The collection spans many years of collection, some cards even date back to early 1900s, but there are cards made even before this
The condition of your cards vary too and are grade according to the 10-point PSA grading standards. (Grading table)
Everytime you purchase a card, you must know the date of purchase, cost of purchase, the market value of that purchase, whom you purchased it from, sport, the individual on the cards, card number and etc.
After completion of purchase, you send the card out for grading about a week later, you want to be able to keep track on when the card was sent out for grading, status of the grading, graded assigned to the card , when it was return by the grading company and receipt of the returned card. for tax purposes, you also want to know the fee paid for the grading service (grade table)
you do buy and sell cards, so you also want to know how much you sold the card for for, when it was sold, to whom it was sold, shipping fee if applicable and any relevant data pertinent to sale transaction. You are free to include any additional data that you believe is important to the table.
Here is my current database so far... I feel like i am missing something and I did not follow the requirements properly
It looks like a pretty good start. I have the following observations about your tables/structure:
CardSellers: should only store info about the CardSeller; the only values it should have are SellerID and SellerName
Vendor: should not have CardId
Grade: SellerID doesn't belong here
Card: looks good
CardBuyers should not have DateOfPurchase or CostOfCard or Shipping Fee; those three members belong in CardTransaction. In fact, "DateOfPurchase" should be "DateOfTransaction"
Also, since the Vendor table should only store Vendor data, and the Card table should only store card data, you also need a M2M (many-to-many) table to connect the two; this should have three members: ID (PK), CardId (FK), and VendorId (FK)
UPDATE
Remember two things about table design:
(0) A table should only contain data about the object its named for and only references to other tables (via a FK - see below)
(1) DRY (Don't Repeat Yourself - IOW, don't store the same data in multiple places; instead, store a link to it, where needed, via FK (Foreign Key) fields referencing PK (Primary Key) fields).
As far as the actual design of the tables, this makes sense to me:
CARDS
-----
CardId (PK)
VendorId (FK)
CardFirstName
CardLastName
CardType
CardYear
MarketValue
Rarity
CollectionNumber
COLLECTORS (Buyers and/or Sellers; no need to have separate tables for them)
---------
CollectorId (PK)
CollectorName
CollectorAddress
TRANSACTIONS
------------
TransId (PK)
CardId (FK)
BuyerId (FK) <= CollectorId in the Collectors table
SellerId (FK) <= CollectorId in the Collectors table
TransactionDate
Price (if it may differ from CARDS.MarketValue)
GRADE
-----
GradeId (PK)
CardId (FK)
Points
AssignedGrade
Qualifiers
Status
CardFee
GradedDate
ReturnedDate
VENDORSLU ("LU" stands for "Lookup")
---------
VendorId (PK)
VendorName
CARDTYPESLU
-----------
CardTypeID (PK)
CardTypeDescription
RARITYLU
-----------
RarityID (PK)
RarityDescription
You may find there are other fields you need to add, too, but that should be close. You might even want additional lookup tables, such as for "Qualifiers" and "Status" in the GradeTable.
You might also want a SPORTSLU table, and then add a SportId FK to the CARDS table (where if SportId == 1, it's a football card, if it's 2, it's a basketball card, &c).
Note, though, that as prevalent and historically significant as Relational Databases are, there is another animal called "Non-SQL" databases (such as MongoDB) which are more free-form/loosey-goosey/I'm okay-you're okay/anarchistic, which allow you to have records, or "documents" that can omit or add whatever members it wants on the fly. Relational Databases can be compared to Classical music (Bach, Mozart, &c) whereas Non-SQL are more like Jazz (free-flowing, improvisational).
And BTW, why no mention of Tiddlywinks? Football, Baseball, etc., are fine, but no Tiddlywinks (or Bocci Ball, for that matter)?!?
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!
I'm new to databases so this might be a stupid question with stupid wordings.
Consider a database table Players and another one, Team.
Instances from Team all have a property players which is an array consisting of the players in that particular team.
Is it then possible to automatically link those players to instances from the Players table? If I wanted to update a value for one of the Players instances, the linked player in the Team table would automatically update itself. This would be the desired behaviour. Is it possible?
For the record I'm using sqlite3 with node.js if that makes any difference. I would however regard this as a general database-related question.
in a relational model these are called the KEYS.
One is a PRIMARY KEY to identify the Player and team instances, then that is used as a reference in the other table and called a FOREIGN KEY.
the table structure would look similar to this:
Team
-------------
team_id
name
Player
-----------
player_id
name
team_id
Or, if you want the same player to possibly be on multiple teams - then like this:
team
---------
team_id
name
player
---------
player_id
name
roster
-------------
team_id
player_id
then you query the structure to find the answer you want: e.g. which players are on team 1:
first design
SELECT * FROM player WHERE team_id = 1
second design
SELECT * FROM player p, roster r
WHERE r.team = 1
AND r.player_id = p.player_id
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.