Colin Wetherbee wrote:
Colin Wetherbee wrote:
Phillip Smith wrote:
As a side note - all the IATA codes are unique for each airport -
wouldn't it be better to use these as the Primary Key and Foreign
Keys? Then you wouldn't have to even join the tables unless you
wanted the port names (not just the code)
This is true, but FWIW, my application will mostly be joining for the
name of the airport or the city, not the code.
I'll keep the idea of using the codes as keys in mind, though. Thanks
for pointing that out.
Oh, now I remember why I'm using IDs as keys. ;)
The code isn't always going to be an airport, and, for example, a train
station in Buenos Aires could conceivably have the same code as a
shipping port in Rotterdam, which, in turn, might well be JFK. :)
Note that IATA codes are _NOT_ unique. The current list of IATA
trigrams list upward of 300 duplicate codes. If you include the train
stations, there might be additional collisions.
You could consider using the ICAO four-letter identifiers instead. They
are unique, and are preferred by airspace management authorities. A
mapping to the corresponding IATA code exists.
--Magne
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
