Projekt bazy danych: klucz złożony a klucz podstawowy jednej kolumny

Aplikacja internetowa, nad którą pracuję, napotkała nieoczekiwany „błąd” - baza danych aplikacji ma dwie tabele (między innymi) o nazwie „Stany” i „Miasta”.

'Państwa„pola tabeli:

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

'idStates'to klucz podstawowy automatycznie zwiększający się.

'Miasta„pola tabeli:

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

'idAreaCode„jest kluczem podstawowym składającym się z kodu kraju + numeru kierunkowego (np. 91422, gdzie 91 to kod kraju dla Indii, a 422 to numer kierunkowy miasta w Indiach). 'idStates„jest kluczem obcym pochodzącym od”Państwa„stół do kojarzenia każdego miasta w”Miasta'tabela z odpowiadającym państwem.

Uznaliśmy, że kombinacja kodu kraju + kodu obszaru będzie unikalna dla każdego miasta, a zatem będzie mogła być bezpiecznie używana jako klucz podstawowy. Wszystko działało. Ale lokalizacja w Indiach znalazła nieoczekiwaną „wadę” w projekcie bazy danych - Indie, podobnie jak USA, są demokracją federalną i geograficznie podzielone na wiele stanów lub terytoriów związkowych. Zarówno dane stanów, jak i terytoriów związkowych są przechowywane w „Państwa' stół. Jest jednak jedno miejsce -Chandigarh - który należy do DWÓCH stanów (Haryana iPendżab) i samo w sobie jest terytorium związkowym.

Oczywiście obecny projekt db nie pozwala nam przechowywać więcej niż jednego rekordu miasta ”Chandigarh”

Jednym z proponowanych rozwiązań jest utworzenie klucza podstawowego łączącego kolumny ”idAreaCode' i 'idStates”

Chciałbym wiedzieć, czy jest to najlepsze możliwe rozwiązanie?

(FYI: używamy MySQL z silnikiem InnoDB).

Więcej informacji:

Baza danych przechowuje informacje meteorologiczne dla każdego miasta. Zatem stan i miasto są punktem wyjścia każdego zapytania.Świeże dane dla każdego miasta są wstawiane codziennie przy użyciu pliku CSV. Plik CSV zawiera kolumnę idStates (dla stanu) i idAreaCode (dla miasta), która służy do identyfikacji każdego rekordu.Normalizacja bazy danych jest dla nas ważna.

Uwaga: Powodem nieużywania automatycznego klucza podstawowego dla tabeli miast jest to, że baza danych jest aktualizowana codziennie / co godzinę za pomocą pliku CSV (który jest generowany przez inną aplikację). Każdy rekord w pliku CSV jest identyfikowany przez kolumnę idStates i idAreaCode. Dlatego preferowane jest, aby klucz podstawowy używany w tabeli miasta był taki sam dla każdego miasta, nawet jeśli tabela zostanie usunięta i ponownie odświeżona. Kody pocztowe (lub kody PIN) i kody obszarów (lub kody STD) spełniają kryteria unikalności, statyczności (nie zmieniają się często), a ich lista jest łatwo dostępna. (Na razie zdecydowaliśmy się na kody obszaru, ponieważ Indie są w trakcie aktualizacji kodów PIN do nowego formatu).

Therozwiązanie zdecydowaliśmy, że zajmiemy się tym na poziomie aplikacji, zamiast wprowadzać zmiany w projekcie bazy danych. W bazie danych będziemy przechowywać tylko jeden rekord „Chandigarh”. W aplikacji stworzyliśmy flagę dla każdego wyszukiwania „Chandigarh, Pendżab” lub „Chandigarh, Haryana”, aby przekierować wyszukiwanie do tego rekordu. Tak, to nie jest idealne, ale akceptowalny kompromis, ponieważ jest to jedyny wyjątek, na jaki dotąd natknęliśmy się.