2010-12-31 7 views
1

BEISPIEL 1:Wie entwerfen "Country", "Province" und "City" Tabellen?

xTable: xTableID, CountryName, PovinceName, CityName 
  • OR

BEISPIEL 2:

Country: CountryID, CountryName 
Province: ProvinceID, ProvinceName 
City: CityID, CityName 

Frage:

  1. Empfiehlst du mir, Länder-, Provinz- und Stadtlisten auf Anwendungsebene zu füllen und dann BEISPIEL 1 Design zu verwenden? oder Soll ich es auf DB-Ebene wie in Beispiel 2 auffüllen?

  2. Die Stadt wird basierend auf der ausgewählten Provinz (falls vorhanden) oder dem Ländernamen angezeigt. Die Provinz (falls vorhanden) wird basierend auf dem gewählten Land angezeigt. Provinz wird nur für ein Land sein und Stadt wird nur für eine Provinz/Land sein. Niemand/viele zu viele Beziehungen, so entworfen ich es wie unten

HINWEIS: jedes Land eine Stadt sicher hat, aber nicht jedes Land eine Provinz Namen hat.

Country: CountryID (PK), CountryName 
Province: CountryID (PK - FK), ProvinceName 
City: CountryID (PK - FK), CityName 

Antwort

2

Sie benötigen eine direkte Beziehung von Stadt zu Land, Provinz zu Land und Stadt zu Provinz. Alle Provinzen sind in einem Land, daher benötigt die Provinztabelle eine CountryID als FK. Ebenso sind alle Städte in einem Land, also dort gleich. Da nicht alle Länder Regionen haben, die Provinzen genannt werden können, können sie nicht zur Navigation von Stadt zu Land verwendet werden. ProvinceID sollte in der Tabelle City sein, aber Nullwerte zulassen.

Alternativ können Sie virtuelle Provinzen (z. B. Provinzname = Keine Provinz) für Länder ohne Provinzen einrichten und sie verwenden, um Stadt zu Land zu beziehen. Das würde auch funktionieren, wenn es eine Stadt gäbe, die sich in einem Land mit Provinzen befände, aber selbst nicht in einer Provinz wäre (wenn so etwas existiert, ist möglicherweise die Provinz IS die Stadt).

+0

Ich habe mir einen anderen Vorschlag ausgedacht, der auf Sie zutrifft. Ich erstelle eine neue Tabelle mit folgenden Spalten: ID, CountryID, ProvincialID, CityID. Ich weiß, das trifft viele zu viele Beziehungen, aber es sieht einfacher zu handhaben aus. Haben Sie Anmerkungen zum angegebenen Design? – user311509

+0

Ich kann nicht sagen, dass ich es sehr mag. Es hängt davon ab, wie wichtig es für Sie ist, strikte Beziehungen zwischen Ihren Entitäten aufrechtzuerhalten.Das Tabellen-Design verhindert nicht, dass eine Stadt mit mehreren Ländern in Beziehung steht, Sie müssten dies programmatisch tun, was zu Fehlern führen könnte. Wenn Sie Ihre Datenbank verwenden möchten, um strikte Beziehungen aufrechtzuerhalten, ist dies nicht der richtige Weg. Auf der anderen Seite, wenn Sie nur an einer schnellen und dreckigen Reparatur interessiert sind, um etwas Code zu bekommen, dann wird es wahrscheinlich gut funktionieren :-) Sie brauchen wirklich Ihre CityID als Primärschlüssel. Also würde ich mit einer der beiden obigen Lösungen gehen. –

+1

Randbemerkung: Ich gehe davon aus, dass Sie mit den Daten wie Filter Dropdown-Werte basierend auf der Wahl von Land und Provinz etwas tun möchten. Um Verzweigungscode zu vermeiden, wäre die virtuelle Provinzlösung (wo eine imaginäre Provinz für jedes Land ohne Provinzen erstellt wird) am einfachsten. Vielleicht möchten Sie prüfen, ob ein Land nur eine imaginäre Provinz hat und in diesem Fall das Dropdown-Menü für die Provinz deaktivieren. Sie können das Dropdown-Menü für Städte auch dann vorladen, wenn ein Land nur eine Provinz hat (imaginär oder nicht). –

0

Ich schlage vor, Sie ProvinceId hinzufügen und CityId zu den Tabellen Provinz und Stadt. Eine Provinz kann viele Städte haben, ebenso kann ein Land viele Provinzen haben. Keine Notwendigkeit, countryId in der Stadt zu behalten, ProvinceId würde genug sein, da es durch Provinz aber nicht Land ausgelöst wird.

+0

Nicht alle Länder haben Unterteilungen, die man Provinzen nennen könnte (man denke an die Vatikanstadt). Gleichermaßen haben andere Landkreise mehrere Unterteilungsebenen (z. B. Vereinigtes Königreich: die einzelnen Länder sind in Landkreise unterteilt). – Richard

Verwandte Themen