sql - 一个列在不同的表中都有它的外键

Question

我在 SQL Server 2008 中有以下表格：

Academic, Experience, Seeker, Employee, Job, Company, City

所有这些表都有一个LocationId列是使用的外键，它引用CityId并且cityId是表的一列City。

如何通过引用检索每个表的城市名称cityid？

假设我想同时知道，求职者的城市，他获得学位的城市，他获得经验的组织城市，宣布职位空缺的工作城市。

Answer 1

Try something like this:

SELECT Academic.FieldName, City.CityName
FROM Academic
JOIN City ON City.CityID = Academic.LocationID

I hope this helps.

UPDATE

Based on the idea that we can connect Academic.AcademicID with Seeker.SeekerID in order to follow the same person, here is another approach:

SELECT a.FieldName, 
ac.CityName AS AcademicCity,
sc.CityName AS SeekerCity
FROM Academic a
INNER JOIN City ac 
ON ac.CityID = a.LocationID
LEFT JOIN Seeker s
ON s.SeekerID = a.AcademicID
LEFT JOIN City sc 
ON sc.CityID = s.LocationID

Here I am showing both inner joins and left joins. (You should avoid the old-fashioned "comma" syntax for inner joins, like "FROM table1, table2", since this is sometimes ambiguous or incorrect.)

The inner join assumes that we can find matching records in the Academic table and the City table; if there is no match, then no records are returned.

But I want to return the Academic City even if there is no match in the Seeker table. That's why I used a left join there, and for the Seeker City as well. If there is no match, the original record is still returned, but the Seeker City will come back NULL.

So a left join allows NULLs in the table that is being left joined. Notice we still have to start with a record in the Academic table. You should choose the table that you want to start with carefully. It doesn't have to be the Academic table. You could start with the Seeker table and left join to the Academic table:

FROM Seeker s
LEFT JOIN Academic a
ON a.AcademicID = s.SeekerID

This will return different results depending on the records in each table. You have to be careful when you decide which table to start with, and when to use inner joins and left joins. It depends on what you are trying to do, and you have to understand clearly exactly what question you want to ask the database.

There is also a separate problem with these tables. It is generally considered poor database design to have a table structure where Academic.AcademicID matches Seeker.SeekerID. Each table should have its own primary key (PK), which doesn't depend on any other table. A table can also have foreign keys (FK) that point to the PKs of other tables. So the properly normalized structure here would start with a Person table with a PersonID PK. The Academic table would have its own AcademicID PK, but it would also have a PersonID FK that points back to the Person table. And so on.

By the way, it's perfectly good normalized database design for many tables to have FKs pointing to a single table. So it's not a problem that many tables (Academic, Seeker, etc) all point to City.CityID. Usually you will see the FK named the same as the PK, e.g., Academic.CityID instead of Academic.LocationID, but calling it LocationID is okay too.