Um aplicativo da Web em que estou trabalhando encontrou um 'bug' inesperado - o banco de dados do aplicativo tem duas tabelas (entre muitas outras) chamadas 'Estados' e 'Cidades'.

'Estados'campos de tabela:

-------------------------------------------
idStates   |   State   |   Lat   |   Long
-------------------------------------------

'idStates'é uma chave primária de incremento automático.

'Cidades'campos de tabela:

----------------------------------------------------------
idAreaCode   |   idStates   |   City   |   Lat   |   Long
----------------------------------------------------------

'idAreaCode'é uma chave primária que consiste no código do país + código de área (por exemplo, 91422, em que 91 é o código do país para a Índia e 422 é o código de área de uma cidade na Índia). 'idStates'é uma chave estrangeira derivada de'Estados'mesa para associar cada cidade no'Cidades'tabela com seu Estado correspondente.

Pensamos que a combinação código de país + código de área seria única para cada cidade e, portanto, poderia ser usada com segurança como chave primária. Tudo estava funcionando. Mas um local na Índia encontrou uma “falha” inesperada no design do banco de dados - a Índia, assim como os EUA é uma democracia federal e está geograficamente dividida em muitos estados ou territórios de união. Os dados dos estados e territórios da união são armazenados noEstados' mesa. Existe, no entanto, um local -Chandigarh - que pertence a DOIS estados (Haryana ePunjab) e também é um território da união por si só.

Obviamente, o design atual do db não nos permite armazenar mais de um registro da cidade.Chandigarh'.

Uma das soluções sugeridas é criar uma chave primária combinando as colunasidAreaCode'e'idStates'.

Gostaria de saber se esta é a melhor solução possível?

(FYI: estamos usando o MySQL com o mecanismo InnoDB).

Mais Informações:

O banco de dados armazena informações meteorológicas para cada cidade. Assim, o estado e a cidade são o ponto de partida de cada consulta.Dados atualizados para cada cidade são inseridos todos os dias usando um arquivo CSV. O arquivo CSV inclui uma coluna idStates (para estado) e idAreaCode (para cidade) que é usada para identificar cada registro.A normalização do banco de dados é importante para nós.

Nota: O motivo para não usar uma chave primária de incremento automático para a tabela de cidades é que o banco de dados é atualizado todos os dias / horários usando um arquivo CSV (que é gerado por outro aplicativo). E cada registro no arquivo CSV é identificado pela coluna idStates e idAreaCode. Por isso, é preferível que a chave primária usada na tabela da cidade seja a mesma para todas as cidades, mesmo se a tabela for excluída e atualizada novamente. CEPs (ou códigos PIN) e códigos de área (ou códigos STD) atendem aos critérios de serem únicos, estáticos (não mudam com frequência) e uma lista pronta deles está facilmente disponível. (Por enquanto, decidimos por códigos de área porque a Índia está atualizando seus códigos PIN para um novo formato).

osolução decidimos usar isso no nível do aplicativo, em vez de fazer alterações no design do banco de dados. No banco de dados, estaremos armazenando apenas um registro de 'Chandigarh'. No aplicativo, criamos um sinalizador para qualquer pesquisa de 'Chandigarh, Punjab' ou 'Chandigarh, Haryana' para redirecionar a pesquisa para esse registro. Sim, não é o ideal, mas um compromisso aceitável, já que esta é a ÚNICA exceção que encontramos até agora.