¿Cuál es la mejor manera de diseñar una ciudad, estado, mesa de campo?

Question

Necesito ayuda para diseñar mi país, ciudad, tablas de estado. Proporcionaré datos de muestra de mi tabla para que pueda ayudarme a resolver mi problema.

Ésta es mi tabla de país:

Country 
______ 
code name 
US  United States 
SG  Singapore 
GB  United Kingdom 

Esta es mi mesa de la ciudad:

City 
_____ 
id country city  state 
1 US  Birmingham Alabama 
2 US  Auburn  Alabama 
. 
. 
29 GB  Cambridge NULL 
30 GB  Devon  NULL 

Mi problema es que el único país que tiene el campo estado es los EE.UU.. Todas las otras ciudades tienen un valor nulo.

Mi solución temporal para esto es crear una tabla de ciudad especial para los Estados Unidos, luego todos los demás países tienen otra tabla de ciudad que no tiene el campo de estado.

Creo que esto solo complicará el asunto, porque tengo dos tablas para ciudades.

¿Cómo puedo mejorar este diseño?

Answer 1

¿Por qué no un conjunto de tablas vinculadas de 3 vías estándar?

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) 
); 

Este aguantará para la mayoría de los casos, a excepción de unos pocos degenerados como Lloydminster, Saskatchewan, a caballo entre dos fronteras provinciales.

Answer 2

¿Por qué no ir relacional?

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

El nombre 'Región' es mucho más genérico que el Estado, lo que significa que probablemente tenga más sentido en cualquier lugar.

Answer 3

Hay muchos países además de los Estados Unidos que tienen divisiones políticas entre el nivel nacional y el municipal. Australia tiene estados, Canadá tiene provincias, Japón tiene prefecturas, etc.

La pregunta es ¿cómo rastreas esta información y la mantienes constante? Podría tener un "registro ficticio" en el nivel medio para los países que no tienen uno. Otra forma de manejar esto es desnormalizar claves externas a todos los niveles hasta la entidad que contiene la dirección. Si el país y la ciudad son obligatorios, sus claves externas no serían aceptables, mientras que su FK estatal podría ser anulable.

Si va por la ruta de desnormalización, necesitará la lógica de la aplicación para asegurarse de que sus claves foráneas son coherentes entre sí.

Si va a la ruta de registro de estado ficticio, necesitará la lógica de la aplicación para asegurarse de que las capas ficticias estén ocultas para los usuarios en la interfaz de usuario.