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
Related
I'm currently working on a project in which i'm about to make a conceptual model for car retail. My major problem is dealing with 1 to 1 realtionship between Invoice_Line table, which is obviously in N-1 relationship with Invoice table, and a table called Car which is supposed to hold information about specific car with it's unique registration number. As far as i know it wouldnt be a problem if i have made the Car table containing only information about specific type of a car, that is it's model, class, etc. However what i want is the invoice looking like that:
...car_registration_number... ...price... ...date...
...
That would mean making a 1 to 1 realtionship between invoice_line and table with specific car_id's, which i want to avoid at all cost. What are the further possibilities to solve that? Because of distinguishable car's each invoice line would hold only 1 car, which is my way of designing it.
An invoice line appears in one invoice so say so in Invoice_Line:
UNIQUE NOT NULL (invoice, invoice_line_number)
The invoices must all appear in Invoice so say so:
FOREIGN KEY (invoice_number) REFERENCES Invoice (invoice_number)
A car is unique in Invoice_Line so say so:
UNIQUE NOT NULL (car_registration_number)
The cars must all appear in Car so say so:
FOREIGN KEY (car_registration_number) REFERENCES Car (car_registration_number)
There is a 1:1 relationship between invoice lines and invoiced cars. But it is not a problem because that relationship is represented by car + invoice line pairs (car + invoice + invoice line number triplets) in Invoice_Line.
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 trying to design a Database for a Patient record.
I am stuck at one point when dealing with Medicine List.
"Table_Patient_Record" - is having a field - "Medicine_Ids" ...
and "Table_Medicine_Record" - having unique - "Id" & "Medicine_Name" ...
Now, my problem is, How to hold multiple(variable) "Id" of "Table_Medicine_Record" into "Medicine_Ids" of "Table_Patient_Record"?
Since, the number of medicines belong to a patient varies from other patients.
Then, how to design database so that from a UI we can Insert, Update and Select.
Thanks, I hope my question is to clear to understand.
If I'm correct, you have a database 'Patients' and 'Medicines'.
The easiest solution is to create a table 'PatientMedicines' that holds a userid and a medicineid.
This way you can connect multiple patients to multiple medicines and the other way around.
And still leaves the freedom that a patient does not need to have any medicine.
Hope this helps.
This seems like a many to many relationship to me. One patient can use multiple medicine, and a medicine can be used by multiple patients. Use a junction table that holds the patient id and the medicine id. Like this:
PatientId | MedicineId
1 1
1 2
2 1
2 3
Lets say we have three tables: Cars, People, Companies.
We want the owner of the car to be a people or a company. The structure of the Cars table is: Car_id, Car_model, Owner_id
What is the best way to do that?
If you can't change the current structure of the cars table, then you could add new table called owners with the following columns:
number id -- unique key
number owner_id -- this is the actual owner id
char owner_type -- this is a value indicating whether the owner is a person or a company
You will then need to cross reference cars with owners and look at the value of owner_type to determine which table to get your owner data from.
EDIT
Forgot to mention (rather important):
In the cars table, populate the owner_id with the owners.id column.
What about having another field in Cars table as "Owner_type_id" which will determine if owner is a person or a company or any other thing. Of course, you should keep another table "Owner_Types" for this scenario to work.
As Igby mentioned, your existing structure is far from ideal, but if you're stuck with it, one option is to have a new Owner table that has the owner_id from the Car table as well as a person_id and a company_id, only one of which would need to be populated.
I have a table of Students and a table of Courses that are connected through an intermediate table to create a many-to-many relationship (ie. a student can enroll in multiple courses and a course can have multiple students). The problem is that the client wants a unique student ID per course. For example:
rowid Course Student ID (calculated)
1 A Ben 1
2 A Alex 2
3 A Luis 3
4 B Alex 1
5 B Gail 2
6 B Steve 3
The ID's should be numbered from 1 and a student can have a different ID for different course (Alex for example has ID=2 for course A, but ID=1 for Course B). Once an ID is assigned it is fixed and cannot change. I implemented a solution by ordering on the rowid of the through table "SELECT Student from table WHERE Course=A ORDER BY rowid" and then returning a number based on the order of the results.
The problem with this solution, is that if a student leaves a course (is deleted from the table), the numbers of the other students will change. Can someone recommend a better way? If it matters, I'm using PostgreSQL and Django. Here's what I've thought of:
Creating a column for the ID instead of calculating it. When a new relationship is created assigning an ID based on the max(id)+1 of the students in the course
Adding a column "disabled" and setting it True when a student leaves the course. This would involve changing all my code to make sure that only active students are used
I think the first solution is better, but is there a more "database centric way" where the database can calculate this for me automatically?
If you want to have stable ID's, you certanly need to store them in the table.
You'll need to assign a new sequential ID for every student that joins a course and just delete it if the student leaves, without touching others.
If you have concurrent access to your tables, don't use MAX(id), as two queries can select same MAX(id) before inserting it into the table.
Instead, create a separate table to be used as a sequence, lock each course's row with SELECT FOR UPDATE, then insert the new student's ID and update the row with a new ID in a single transaction, like this:
Courses:
Name NextID
------- ---------
Math 101
Physics 201
Attendants:
Student Course Id
------- ------ ----
Smith Math 99
Jones Math 100
Smith Physics 200
BEGIN TRANSACTION;
SELECT NextID
INTO #NewID
FROM Courses
WHERE Name = 'Math'
FOR UPDATE;
INSERT
INTO Attendants (Student, Course, Id)
VALUES ('Doe', 'Math', #NewID);
UPDATE
Courses
SET NextID = #NewID + 1
WHERE Course = 'Math';
COMMIT;
Your first suggestions seems good: have a last_id field in the course table that you increase by 1 any time you enroll a student in that course.
Creating a column for the ID instead
of calculating it. When a new
relationship is created assigning an
ID based on the max(id)+1 of the
students in the course
That how I'd do it. There is no point of calculating it. And the id's shouldn't change just because someone dropped out.
Adding a column "disabled" and setting
it True when a student leaves the
course.
Yes, that would be a good idea. Another one is creating another table of same structure, where you'll store dropped students. Then of course you'll have to select max(id) from union of these two tables.
I think there are two concepts that you need to help you out here.
Sequences where the database gets the next value for an ID for you automatically
Composite keys where more than one column can be combined to make the primary key of a table.
From a quick google it looks like Django can handle sequences but not composite keys, so you will need to emulate that somehow. However you could equally have two foreign keys and a sequence for the course/student relationship
As for how to handle deletions, it depends on what you need from your app, you may find that a status field would help you as you may want to differentiate between students who left and those that were kicked out, or get statistics on how many students leave different courses.