I'm trying to create a database schema for Game achievements which should include these:
Users:
username,
avatar image file location,
achievements their received in each game
Each achievement has
achievement name
achievement level
achievement type
a game that achievement was part of. Each achievement is specific per game. You can’t have the same achievement across different games
Each game has a title and game type.
It also must have clear relationship definitions (crow’s feet for 1 to many), primary key and foreign keys should be marked.
I've started it but I'm not sure if I did it right and I'm not really sure which of the information types are supposed to be primary keys and which supposed to be foreign keys
The image shows what I have so far and where I'm stuck (stuck on the keys)
So this is what I've gotten now after some comments had explained a bit of this for me
But I'm still not really sure if I did these foreign keys correctly
Primary keys must be unique value, You should give appropriate primary keys for each, as:
Users: user_id,
games: game_id,
achievements: achievement_id,
Then you can specify the foreign keys accordingly, like in achievements, user_id, and game_id will be foreign keys.
Any key that you want to make foreign key then their should be a table where that key present as a primary key.
in your case Users table
username primary key
avtar_image
achievment_name (foreign key) reference to Achievements table (achievment_name)
if you want game also in user table then add a new column in User table
game_title (foreign key) reference to Game table(game_title)
Related
I have problem related to my database. I have user table, which I don't think I need to explain but then i got game table. After each game it will save record of which user was winner and which was loser. What type of relation should I use? I was thinking about many to many. User can have many games and also ech game can have same user winning multiple game as well as losing many games.
Am I right?
A foreign key is a column or a set of columns in one table that references the primary key columns in another table. The primary key is defined as a column (or set of columns) where each value is unique and identifies a single row of the tabl
I have an application that has coaches, clients and workouts.
One coach can have many clients and one client can have many coaches = many to many
One coach can create many workouts and one workout can only be created by one coach = one to many
Also, one client can create many workouts and one workout can only be created by one client = one to many
My problem here is that a workout could only be created by either a coach or a client. Not both. What’s the best way to structure the tables and fields then?
Right now I have a workout that has id: Pk, coachId: Fk, clientId: Fk. But that means that either coachId or clientId are gonna be null on every row. I guess that’s not best practice?
I’ve also thought of just having one user table with a role table connected to it. But I don’t think that’s gonna be optimal/possible since a coach and a client are gonna have many different fields and relations (eg a coach could have certificates and diplomas and a client needs to be able to be assigned to a workout). Also a client need to be able to be assigned to one or many coaches and vice versa.
Current design:
Coach Client Workout CoachClient (composite)
id id id coachId Fk
coachId Fk clientId Fk
clientId Fk
You are on the right path by having two separate FKs (foreign keys) on the table workout.
Now, to make sure only one of the FKs is always null and the other FK is always NOT null you can add a constraint:
create table workout (
id int primary key not null,
coach_id int,
client_id int,
constraint fk1 foreign key (coach_id) references coach (id),
constraint fk2 foreign key (client_id) references client (id),
constraint chk1 check (coach_id is null and client_id is not null
or coach_id is not null and client_id is null)
);
The magic is in the last constraint chk1. It enforces that one and only one of them is not null.
Clients and Coaches are both Persons. So having one table solves your FK problem.
However, if there are a lot of differences in the columns of "clients" and "coaches", then this probably cause more problems than it cures.
Please note that
Foreign Keys have only a small number of properties; you are asking for more than they can give.
A Foreign key implicitly creates an index, to assist with performance; you can build the INDEX without having an FK.
A Foreign key is a 'constraint' that is checked at runtime. Since your complicated check can't be handled by an FK, maybe you should abandon the FK?
I am trying to figure out relationships between my tables and the notion of how it all inter-relates is not clear.
Lets say I have a Person table (first name, last name, etc) where the Primary key is social security number.
I also have a Fireman table that has just 2 columns -- date when joined the fire company, and a unique fireman number. The 3rd column would be a link back to the Person table.
Initially, I made SSN in the Fireman table to be a foreign key linking to SSN in the Person table. But doesnt it imply that every time I create a new Fireman, I can re-use the same SSN over and over? The foreign key constraint would not be violated -- so its "all good" -- but its not what I want. Does it make sense? I dont want to allow for different unique Fireman numbers all sharing the same SSN number. So how do I set this up -- whats Primary, whats foreign, whats one to one and whats one to many.
A key can be primary and foreign all at the same time in a one-to-one relationship.
You can scrap your primary key from the Fireman table, and just use SSN as the unique key. Since it's one-to-one, there's no need for a separate identifier.
Alternatively, you could create a unique index on the column SSN in your fireman table. That would prevent duplicate entry.
Note that data validation, relationships and indexes are all separate things. You can use indexes and relationships to validate data, but you can also use different concepts, like constraints.
I have 2 Primary key tables and 1 Compound table.
I want to have some other information apart from the 2 primary keys from the primary key table in the compound table.
Would I just repeat this data or is their a way to add other fields into a the compound field without repeating it?
Thanks.
Your current design looks close to right. But I think your EventVolunteer table should look like this:
CREATE TABLE EventVolunteer (
eventID INTEGER,
volunteerID INTEGER,
FOREIGN KEY eventID REFERENCES Event(eventID),
FOREIGN KEY volunteerID REFERENCES Volunteer(volunteerID),
PRIMARY_KEY(eventID, volunteerID)
)
This bridge table should exist to store relationships between events and their volunteers, and nothing else. All metadata for events and volunteers should be in the Event and Volunteer tables, respectively.
If you need to bring in some information, then you can do so via joining the Event and Volunteer tables with this bridge table. This join is much less of a penalty than you might think, if you have indices setup in the right places.
I am creating a desktop application which will test users knowledge of particular subject, by asking multiple choice questions. Each question contains unique question number, problem, four options, correct answer, topic and difficulty. I have a database of such question. For each user, i want to keep a track of questions he has attempted, so that i may provide him his progress analysis and also to provide better quality of question. How may I store required data for each user?
I already have a database of users details and one of questions in mySQL.
You should have three tables:
Users
Questions
Scores
The users table will have a primary key eg,
PRIMARY KEY (userID)
The Questions table will also have a primary key.
Finally the Scores table will have a primary key and two foreign keys referencing the users and questions tables eg.
PRIMARY KEY (scoreID),
FOREIGN KEY (userID) REFERENCES Users(userID),
FOREIGN KEY (questionID) REFERENCES Questions(questionID)
The primary key for the scores table cannot be a composite of the two foreign keys because a user may have many different scores for each question. The primary key has to be unique. Of course the scores table will have a score attribute(column) to store the scores for each time.
As for which data types to use, all you need is the int data type for primary keys and the score unless you want to use a more precise type like float for the score. I suggest you use varchar for things like user names.