В веб-приложении, над которым я работаю, обнаружена неожиданная «ошибка»; - База данных приложения имеет две таблицы (среди многих других), которые называются «состояния»; и "города".

'States' table fields:

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

& APOS;idStates& APOS; это автоинкрементный первичный ключ.

'Cities' table fields:

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

& APOS;idAreaCode& APOS; является первичным ключом, состоящим из кода страны + код города (например, 91422, где 91 - код страны для Индии, а 422 - код города в Индии). & APOS;idStates& APOS; является внешним ключом, полученным из & apos;States& APOS; таблица, чтобы связать каждый город в & apos;Cities& APOS; таблица с соответствующим ей государством.

Мы полагали, что комбинация кода страны + кода города будет уникальной для каждого города и, таким образом, может безопасно использоваться в качестве первичного ключа. Все работало. Но место в Индии обнаружило неожиданный «недостаток». в дизайне БД - Индия, как и США, является федеративной демократией и географически разделена на многие штаты или союзные территории. Данные как по штатам, так и по союзным территориям хранятся в & apos;States& APOS; Таблица. Есть, однако, одно место -Chandigarh - который принадлежит двум государствам (Haryana а такжеPunjab), а также является союзной территорией.

Очевидно, что существующий дизайн БД не позволяет нам хранить более одной записи о городе & quot;Chandigarh& APOS ;.

Одним из предложенных решений является создание первичного ключа, объединяющего столбцы & apos;idAreaCode& APOS; и & apos;idStates& APOS ;.

Я хотел бы знать, является ли это наилучшим возможным решением?

(К вашему сведению: мы используем MySQL с движком InnoDB).

Дополнительная информация:

The database stores meteorological information for each city. Thus, the state and city are the starting point of each query. Fresh data for each city is inserted everyday using a CSV file. The CSV file includes an idStates (for state) and idAreaCode (for city) column which is used to identify each record. Database normalization is important to us.

Примечание. Причина, по которой не используется автоинкрементный первичный ключ для таблицы городов, заключается в том, что база данных обновляется ежедневно / ежечасно с использованием файла CSV (который создается другим приложением). И каждая запись в CSV-файле идентифицируется столбцами idStates и idAreaCode. Следовательно, предпочтительно, чтобы первичный ключ, используемый в таблице городов, был одинаковым для каждого города, даже если таблица была удалена и обновлена снова. Почтовые индексы (или пин-коды) и коды городов (или коды STD) соответствуют критериям уникальности, статичности (часто не меняются), и их готовый список легко доступен. (На данный момент мы определились с кодами городов, потому что Индия находится в процессе обновления своих пин-кодов в новом формате).

The solution we decided on was to handle this at the application level instead of making changes to the database design. In the database we will only be storing one record of 'Chandigarh'. In the application we've created a flag for any search for 'Chandigarh, Punjab' or 'Chandigarh, Haryana' to redirect search to this record. Yeah, it's not ideal, but an acceptable compromise since this is the ONLY exception we've come across so far.