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!
Related
I am making an application that will process a big chunk of information. This information was retrieved using some web crawlers and is about news, containing data such as News Title, URL, Publication Date, Category and Content. The crawled data is in XML format, and I will load that information into my application.
From there, 10 users will process every news and tag the category of the news manually by reading the title. I've used 9 main categories to be used, and for each news the users will decide from 0-5 how much this particular news belongs to each category.
Users will also search for news by title and decide if this news is discussing the same event as another news, or if this news is similar to another news (like a news about a football game at 3 PM and a news about a football game at 5 PM).
I have no problems with making the application itself, I just need some help with the part of how to design one/many tables that can link news that talk about similar events or about the same event, since there can be many many news that can talk about the same event.
So far I've done something like this:
Table News
ID
Title
URL
PublicationDate
NewsContent
Table Category
NewsID
User_ID
Economy
Politics
Present_Day
Sport
Technology
Showbiz
Culture
Region
World
Table User
ID
FirstName
LastName
Each category field in the Category table holds a tinyint data type (I'm using SQL Server) and I've restricted the values the user can input via a check constraint so that it allows values from 0 - 5. I don't know if this is the right approach so far for the database design, and I need to add the table/s that allow to add information about similar news or news that talk about the same event, such as a table Similar_News containing some fields like News_ID, SimilarNews1_ID, SimilarNews2_ID and so on, and must contain the information about which user 'said this', but this sounds like a flawed design to me.
Any help is appreciated, thank you.
Here are some suggestions. In the CATEGORY table you have created 9 different columns (economy, politics etc). What if a few days / months / years down the line there is a new category. In this case you will have to modify your database design. Instead, you could have the following structure of your CATEGORY table.
CategoryId
Category
And have one more table to store the actual news categorization.
Table: NewsCategory
NewsId
CategoryId
CategoryWeight (This will store the rating from 1-5)
If the user feels that a news does not belong to a particular category then no row will be inserted in this table for that category. Such a structure will give you more flexibility to insert new categories in future without changing the database design. You just have to insert new rows in the Category table.
For storing similar news I would recommend one of the following approach.
Create a table event and store the details of the event in this table.
EventId
EventDescription
Sample Data
EventId: 55
EventDescription: Euro 2016 Belgium vs Italy
Now you can include this EventId in your News table. This way you can pull up all the news that are related to this event.
Create Similar_News table with n fields to store the similar News_Id doesn't sound a good idea. How many fields would you create? 3? 10?
You are modeling a n to m relationship so I would only use two fields (three if you wanna store the User Id). For example if New 1 is similar to news 2 and 3. And New 3 is similar to 4, you insert the rows:
New_ID SImilar_New_Id
--------------------------
1 2
1 3
3 4
Another approach would be use a NOSQL DB to store flexible structures, for example:
"News":{
"User_Id":1,
"Category"{
"Economy":3,
"Politics":4
},
"Similar_News":[1,2,3]
}
I have to design tables in 0NF for my project, I am required to design the tables in 0NF form first then proceed to normalization and then draw the ERD. However it has been a real challenge for me to obtain the 0NF forms of my tables, lots of time has been wasted trying to redesign so I thought of asking help from people who might be more experienced in database design.
My database is of a Car Rental System. The system should keep records of customers,cars,employees, details of each rental and also the company is supposed to have multiple branches at different locations and each branch must have their own set of unique(identified by their license plate number) cars available.
One customer can have multiple rental records(i.e. made a rental in January then another in March .e.t.c) but one rental record is related to only one customer
A customer can book multiple cars in a single rental
Each rental is made through a single booking agent(an employee)
Employees is divided between Managers and booking agents. Each branch has a single manager but multiple booking agents.
Each branch has multiple cars located there but each car can be located at a single branch
So far, I've come up with these 0NF tables, they don't look correct to me though:
Cars(CarID,LicensePlateNo,Make,Model,Year,Color,mileage,Capacity,seats,Availability, Rate, BranchID,BranchLocation)
Customer(CustomerID, FirstName,LastName, Address ,ContactNo,Gender,DOB,NIC,RentalID,DateRented,RentalCost)
Agent(AgentID,FirstName,LastName,Address,ContactNo,Gender,DOB,NIC,MonthlyRentals,Salary,ManagerID,ManagerName,MangerLastName,ManagerAddress,ManagerContact,BranchID,BranchLocation)
Rental(RentalID,DateRented,Duration,RentalCost,Discount,AgentID,CarID,LicensePlateNo,Make,Model)
Branch(BranchID,BranchName,BranchLocation,ContactNumber,ManagerID)
I have replaced the Agent table with the Employee table and I have added 2 new columns (Position and Manager) to it. I believe the position column should store either 'Agent' or 'Manager'. If employee is an Agent, the Manager field should contain the ID of his/her Manager (EmployeeID). If employee is Manager, most probably the Manager column should be left NULL. I have also removed all other columns which were being repeated(Example BranchLocation in cars table etc...)
Cars(CarID,LicensePlateNo,Make,Model,Year,Color,Mileage,Capacity,Seats,Availability, Rate, BranchID)
Customer(CustomerID, FirstName,LastName,Address,ContactNo,Gender,DOB,NIC,RentalID)
Rental(RentalID,DateRented,Duration,RentalCost,Discount,EmployeeID,CarID)
Branch(BranchID,BranchName,BranchLocation,ContactNumber,EmployeeID)
Employee(EmployeeID,FirstName,LastName,Address,ContactNo,Gender,DOB,NIC,MonthlyRentals,Salary,BranchID,Position,Manager)
Thanks
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.
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
first of all sorry for my bad english hehehe I need some help, I want to design a database for a website, like a mini Amazon. This database will manage every kind of products (TV, cars, computers, books, videogames, penciles, tables, pants...), but also, each product must have some properties (that will be indexed) for example, if the product is a book, the properties will be something like genre, year, author. If the product is a TV, the properties will be something like size, color, also year. And if the product is a car, the properties will be something like year, color, model, for example. So, this is my idea:
One table to manage departments (like electronics, books...)
One table to manage categories of the departments, this table will be a child of the previous. If the department is electronics, here will be audio, tv and video, games... (each category belongs to one department, the relationship is one department to many categories)
One table to manage the products (each product belongs to one category, the relationship is one category to many products)
One table to manage properties (like year, color, genre, model...)
One table to engage products with properties, this table will be called ProductProperties
Im not sure if this is the best way, the database will be huge, I will develop the database on MySQL. But, I think this is not the best way, this article talks about "Database Abstraction: Aggregation and Generalization" http://cs-exhibitions.uni-klu.ac.at/index.php?id=433, in other words generic objects (I think), but this way is old (70s). In this article http://www.simple-talk.com/sql/database-administration/ten-common-database-design-mistakes/ in the section "One table to hold all domain values" says that this is a wrong way... Im saying all of this because of the table ProductProperties, I dont know if I make this table or if I make especific tables for each kind of products.
Do you have any suggestion? Or do you have a better idea?
Thanks in advance, take care!!!
1.One table to manage departments (like electronics, books...)
2.One table to manage categories of the departments, this table will be a
child of the previous. If the
department is electronics, here will
be audio, tv and video, games... (each
category belongs to one department,
the relationship is one department to
many categories)
Why? One table, categories, forming a hierarchy. More flexible.
3.One table to manage the products (each product belongs to one category,
the relationship is one category to
many products)
Why? Allow m:n here. A product in many categorries.
Im not sure if this is the best way,
the database will be huge
Ah - no. Sorry. Nontrivial, yes. Hugh? No. Just to get you an idea of hugh - I have a db I am adding 1.2 billion rows PER DAY to a specific table. On average. THIS is big. YOu end up with what - 100.000 items? not even worth mentioning.
Pablo89, the description of what you want is very close to what the AdventureWorks database for SQL Server does. There are many examples of using AdventureWorks on the Web from web applicatons to reporting to BI.
Download and install SQL Server Express 2008 R2. Download and install the sample database for the above product. Inspect the database design for AdventureWorks.
Use AdventureWorks as examples in questions you may post.
I use AdventureWorks because I use SQL Server. I do not say it is better than other database products I say this because I know AdventureWorks.
I do not think that some database can work fast with 500,000,000 items. Complete tree of products categories for amazon.com contains 51,000 nodes (amazoncategories.info). Also the data is updated hourly, so saved product information can be incorrect. I think the optimal way is to store categories tree only get the product data at runtime using Amazon's API.