Magne Mæhre wrote:
> 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.
I have both ICAO and IATA codes in my database, but users who typically
won't know (or even be aware of) ICAO codes will be using the front end. In fact, in the front end, the users will see
somethinglike the
following (with the respective, unique, application-specific port ID
hidden in the background).
Houston, TX (IAH - George Bush Intercontinental Airport)
New York, NY (JFK - John F. Kennedy International Airport)
Dubai, United Arab Emirates (DXB - Dubai International Airport)
Which should be unique enough. :)
Colin
