How do I setup fields to be dependent on what foreign key is input?
I have googled and searched stack overflow, using similar questions to that, but couldn't find anything that fitted what I was looking for. There are pictures and an example below to better describe what I am asking.
Here's my table (that I want fields to be dependant on there foreign keys):
jo_route is a foreign key for this table:
and jo_type is a foreign key for this table:
When I go to insert a record into the journeys table, and select the route id. How do I get the corresponding information from that foreign keys table to appear in the respective fields in this table.
For example, jo_type as 3 records (as shown in the picture). The foreign key jo_type is linked with this table. Say I select the ID for air (2) in the journeys table. How do I get the related fields (jo_seats_total) to be automatically chosen from the travel types table? So it should appear as 100.
Hopefully I have explained my problem well enough.
Thanks in advance for any help!
Sorry for the long post.
I hope this is something that you looking for...
SELECT t.tt_max_seat, t.tt_name, r.ro_origin, r.ro_destination,
j.jo_seats_total, j.jo_seats_take, j.jo_seats_available
FROM journey j
JOIN route r ON j.jo_route = r.ro_id
JOIN type t ON j.jo_type = t.tt_id
WHERE j.jo_type = 2
Related
I'm making a schema for a hospital data base. I have 4 tables, candidate details, hospital details, position details and interview details. The interview table has a foreign key referring to the candidate table, one to the position's table and I also want it to have one referring to the hospital table but I noticed that it is possible then to have a tuple where the combination of the position id and the hospital id is not the same as the combination that occurs on the position tables (the position table has a foreign key referring to the hospital table) So in other words is makes it possible to enter the incorrect hospital id or position id in the interview table. So for instance on the interview table I could enter a tuple where the position id is 01 and the hospital id is 02 but if you go the positions table, the position id that is being refereed to could easily have a hospital id that is different (eg 03).
I was thinking that there might be away of creating a composite foreign key that refers to two different tables at the same time. If that's not the case, is the only way of resolving the issue, just removing the hospital id column from the interview table completely?
I've been using mySQL workbench so I don't have any of the SQL code on hand but if any extra information (eg ERR image) is required to answer this question I'll try my best to source it.
Short answer :
No, a foreign key constraint always references exactly one parent table.
However, If I understand your situation well, you have 4 tables
candidate details. id
hospital details. id
position details. id, hospital_id
interview details. candidate_id, hospital_id, position_id
The problem is the relation between postion and hospital is many to many
simple way EAV add another table call it hospital_postition, that has all the positions in all hospitals then link each hospital_postition to the condidate in the interview
candidate details. id
hospital details. id
position details. id
hospital_postition. id, hospital_id, position_id
interview details. candidate_id, hospital_position_id
Less is more!
You have this problem because the table isn't in 3rd normal form. hospital_id isn't dependent on the interview, it's dependent on the position, and position_id is not the KEY for this able.
Ask yourself, do I really want to record hospital_id in the interview table? All the information you probably need is already stored in the positions table. The only reason I can think of for wanting that column would be where you were conducting interviews in hospitals other than the one where the position is based. If that is the case then your schema is already correct but your question implies otherwise.
Drop the hospital_id column from the interview table and your problem will magically disappear.
On the subject of getting table definitions (SQL code) out of MySQL Workbench, try this:
Right-click the table name in the schema browser
Select "Send to SQL Editor"
Select "Create statement"
I have a question regarding foreign keys. I have searched for the answer and was unable to location one.
I have a table 'projects' that has the column 'owner_id' which references 'managers.owner_id' as a foreign key.
Would it be possible to reference 'managers.owner_id' as a foreign key, but show the column 'managers.full_name'? When I run a SELECT query against the 'projects' table, I want to see the manager's name to come up and not the manager's id.
If it is possible, is this normally done with the SELECT command or can I configure it when I CREATE/ALTER the 'projects' table?
I am fairly new with MySQL, thank you for your time and patience!
If what I'm asking seems insane, I wouldn't mind hearing what your thoughts are or if you have any other suggestions.
You just need to join the tables and select the fields that you want e.g.
SELECT projects.project_name, managers.full_name
FROM projects
INNER JOIN managers on projects.owner_id = managers.owner_id
If there are projects where the owner_id is NULL but you still want to list it then use a LEFT JOIN instead.
Let's assume I have 2 tables: foo and bar.
In third table I want to store different kind of data, however every row will have a reference to either foo OR bar.
Is it correct if I create 2 NULLable foreign keys - foo_id and bar_id - in the third table, or is it againts database design principles?
Basically, I thought all the time that foreign keys need to ALWAYS have a "parent", so if I try to e.g. INSERT a row with no primary key matched (or, in this case, with a foreign key set to NULL), I will get an error. Nullable FK-s are new to me, and they feel a bit off.
Also, what are the alternatives? Is it better to create separate tables storing single reference? Isn't this creating redundancy?
Linking tables?
Help.
A nullable FK is "okay". You will still get an error when you try to insert a non-existing parent key (it is just NULL that is allowed now).
The alternative is two link tables, one for foo and one for bar.
Things to consider:
Link tables allow for 1:N. If you don't want that, you can enforce it by primary key on the link table. That is not necessary for the id column solution (they are always 1:N).
You can avoid columns with mostly NULL values using link tables. In your case, though, it seems that you have NULL for exactly half the values. Probably does not qualify as "mostly". This becomes more interesting with more than two parent tables.
You may want to enforce the constraint that exactly one of your two columns is NULL. This can be done with the id column version using a check constraint. It cannot be done with link tables (unless you use triggers maybe).
it is depend on the business logic of the program. if the foreign key field must has a value , it is bad to set it null-able .
for example .
a book table has category_id field which the value is reference from bookCategory table.
each record in book table must has category . if for some reason you set it as nullable . this will cause some record in book table with category_id is null.
the problem will show up in report. the following 2 query will return different total_book
select count(*) as total_book from book;
select
count(*) as total_book
from
book
inner join bookCategory
on book.category_id = category.id
my advice is don't use null-able unless you expect value and no-value . alot of complex system that sometime have value different from one report and another , usually is cause by this.
I am in a situation where i have to store key -> value pairs in a table which signifies users who have voted certain products.
UserId ProductID
1 2345
1 1786
6 657
2 1254
1 2187
As you can see that userId keeps on repeating and so can productId. I wanted to know what can be the best way to represent this data. Also is there a necessity of using primary key in here. I've searched a lot but am not able to find the exact specification about my problem. Any help would be appreciated. Thank you.
If you want to enforce that a given user can vote for a given product at most once, create a unique constraint over both columns:
ALTER TABLE mytable ADD UNIQUE INDEX (UserId, ProductID);
Although you can use these two columns together as a key, your app code is often simpler if you define a separate, typically auto increment, key column, but the decision to do this depends on which app code language/library you use.
If you have any tables that hold a foreign key reference to this table, and you intend to use referential integrity, those tables and the SQL used to define the relationship will also be simpler if you create a separate key column - you just end up carting multiple columns around instead of just one.
I'm currently designing a database structure for our team's project. I have this very question in mind currently: Is it possible to have a foreign key act as a primary key on another table?
Here are some of the tables of our system's database design:
user_accounts
students
guidance_counselors
What I wanted to happen is that the user_accounts table should contain the IDs (supposedly the login credential to the system) and passwords of both the student users and guidance counselor users. In short, the primary keys of both the students and guidance_counselors table are also the foreign key from the user_accounts table. But I am not sure if it is allowed.
Another question is: a student_rec table also exists, which requires a student_number (which is the user_id in the user_accounts table) and a guidance_counsellor_id (which is also the user_id in the user_accounts) for each of its record. If both the IDs of a student and guidance counselor come from the user_accounts table, how would I design the student_rec table? And for future reference, how do I manually write it as an SQL code?
This has been bugging me and I can't find any specific or sure answer to my questions.
Of course. This is a common technique known as supertyping tables. As in your example, the idea is that one table contains a superset of entities and has common attributes describing a general entity, and other tables contain subsets of those entities with specific attributes. It's not unlike a simple class hierarchy in object-oriented design.
For your second question, one table can have two columns which are separately foreign keys to the same other table. When the database builds the query, it joins that other table twice. To illustrate in a SQL query (not sure about MySQL syntax, I haven't used it in a long time, so this is MS SQL syntax specifically), you would give that table two distinct aliases when selecting data. Something like this:
SELECT
student_accounts.name AS student_name,
counselor_accounts.name AS counselor_name
FROM
student_rec
INNER JOIN user_accounts AS student_accounts
ON student_rec.student_number = student_accounts.user_id
INNER JOIN user_accounts AS counselor_accounts
ON student_rec.guidance_counselor_id = counselor_accounts.user_id
This essentially takes the student_rec table and combines it with the user_accounts table twice, once on each column, and assigns two different aliases when combining them so as to tell them apart.
Yes, there should be no problem. Foreign keys and primary keys are orthogonal to each other, it's fine for a column or a set of columns to be both the primary key for that table (which requires them to be unique) and also to be associated with a primary key / unique constraint in another table.