what is the best way to design a city, state, country table?

Why not go relational?

Country ( CountryID, CountryCode, CountryName )Region  ( RegionID, RegionCode, RegionName, CountryID )City    ( CityID, CityCode, CityName, RegionID )

The 'Region' name is a big more generic than State, which means it would likely make more sense everywhere.

Why not a standard 3-way linked table set?

table country (   id   int primary key,   name varchar(255));table state (    id int primary key,    name varchar(255),    country_id int foreign key country (id));table city (    id int primary key,    name varchar(255)    state_id int foreign key state (id));

This'll hold up for most cases, except a few degenerate ones like Lloydminster, Saskatchewan, which straddles two provincial borders.

There are lots of countries besides the United States that have political divisions between the national and municipal level. Australia has states, Canada has provinces, Japan has Prefectures, and so forth.

The question is how do you track this information and keep it consistent? You could have a "dummy record" at the middle level for countries that don't have one. Another way to handle this is to denormalize foreign keys to all levels down to the entity containing the address. If country and city are mandatory then their foreign keys would be not nullable whereas your state FK could be nullable.

If you go the denormalization route, you will need application logic to ensure that your foreign keys are consistent with each other.

If you go the dummy state record route, you will need application logic to ensure that dummy layers are hidden from users in the user interface.