Bei einer Webanwendung, an der ich arbeite, ist ein unerwarteter "Fehler" aufgetreten. Die Datenbank der App enthält zwei Tabellen (unter anderem) mit den Namen "Bundesstaaten" und "Städte".

'Zustände'Tabellenfelder:

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

'idStates'ist ein automatisch inkrementierender Primärschlüssel.

'Städte'Tabellenfelder:

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

'idAreaCode'ist ein Primärschlüssel bestehend aus Landesvorwahl + Ortsvorwahl (z. B. 91422, wobei 91 die Landesvorwahl für Indien und 422 die Ortsvorwahl einer Stadt in Indien ist). 'idStates'ist ein Fremdschlüssel abgeleitet von'Zustände'Tabelle für die Zuordnung jeder Stadt in der'Städte'Tabelle mit dem entsprechenden Staat.

Wir stellten fest, dass die Kombination aus Landesvorwahl und Ortsvorwahl für jede Stadt eindeutig ist und somit sicher als Primärschlüssel verwendet werden kann. Alles hat funktioniert. Aber ein Standort in Indien hat einen unerwarteten „Fehler“ im Design der Datenbank entdeckt - Indien ist wie die USA eine föderale Demokratie und ist geografisch in viele Staaten oder Gewerkschaftsgebiete unterteilt. Sowohl die Daten der Staaten als auch der Unionsterritorien werden in der Datenbank gespeichert.Zustände' Tabelle. Es gibt jedoch einen Ort -Chandigarh - das zu ZWEI Staaten gehört (Haryana undPunjab) und ist auch ein Gebiet der Union für sich.

Offensichtlich erlaubt uns das aktuelle DB-Design nicht, mehr als eine Aufzeichnung der Stadt zu speichern. 'Chandigarh'.

Eine der vorgeschlagenen Lösungen besteht darin, einen Primärschlüssel zu erstellen, in dem die SpaltenidAreaCode' und 'idStates'.

Ich würde gerne wissen, ob dies die bestmögliche Lösung ist.

(FYI: Wir verwenden MySQL mit der InnoDB-Engine).

Mehr Informationen:

In der Datenbank werden meteorologische Informationen für jede Stadt gespeichert. Somit sind das Bundesland und die Stadt der Ausgangspunkt jeder Abfrage.Frische Daten für jede Stadt werden täglich mithilfe einer CSV-Datei eingefügt. Die CSV-Datei enthält die Spalten idStates (für Status) und idAreaCode (für Stadt), mit denen die einzelnen Datensätze identifiziert werden.Datenbanknormalisierung ist uns wichtig.

Hinweis: Der Grund dafür, dass kein automatisch inkrementierender Primärschlüssel für die Städtetabelle verwendet wird, besteht darin, dass die Datenbank täglich / stündlich mithilfe einer CSV-Datei (die von einer anderen App generiert wird) aktualisiert wird. Jeder Datensatz in der CSV-Datei wird durch die Spalten idStates und idAreaCode gekennzeichnet. Daher ist es bevorzugt, dass der in der Städtetabelle verwendete Primärschlüssel für jede Stadt derselbe ist, auch wenn die Tabelle gelöscht und erneut aktualisiert wird. Postleitzahlen (oder PIN-Codes) und Ortsvorwahlen (oder STD-Codes) erfüllen die Kriterien, dass sie eindeutig und statisch sind (nicht häufig ändern), und eine fertige Liste dieser Codes ist leicht verfügbar. (Wir haben uns vorerst für Vorwahlen entschieden, da Indien gerade dabei ist, seine PIN-Codes auf ein neues Format zu aktualisieren.)

DasLösung Wir beschlossen, dies auf Anwendungsebene zu erledigen, anstatt Änderungen am Datenbankdesign vorzunehmen. In der Datenbank wird nur ein Datensatz von 'Chandigarh' gespeichert. In der Anwendung haben wir eine Markierung für jede Suche nach "Chandigarh, Punjab" oder "Chandigarh, Haryana" erstellt, um die Suche auf diesen Datensatz umzuleiten. Ja, es ist nicht ideal, aber ein akzeptabler Kompromiss, da dies die EINZIGE Ausnahme ist, auf die wir bisher gestoßen sind.