nicht angemeldet
Hallo,
Wo ist der Vorteil, anstelle des Stadtnamens wiederholt sich hier in Tabelle 3 immer die StadtID.
Köln hat schätzungweise 30 Stadtteile. Bei Deiner Tabelle würdest Du daher den Namen Köln ca. 30 mal eingeben müssen. Für die anderen Großstädte wiederholt sich diese Prozedur. Neben viel Arbeit, stellt diese Variante natürlich eine hohe Gefahr für Tippfehler (Köln,Kölm,Kölln usw.) dar.
Selbst wenn der klassische Tipfehler ausbleibt, gibts immer noch 'Köln' bzw 'KÖLN', welche in einer vernünftigen DB nicht das selbe sind.
Und, zwei Orte können zwar den gleichen Namen haben aber nicht die gleichen Orte sein:-)
Für Stadtteile ist der Arbeitsaufwand noch höher, da sich wahrscheinlich sehr häufig gleiche Stadtteilnamen in unertschiedlichen Städten wiederfinden werden.
Aber, es ist unvernünftig einen Record in Stadtteile mehreren Orten zuzuordnen. Was, wenn ich der Name eines Stadtteils des einen Ortes ändert, der eines anderen nicht. Aus der Traum.
Besser ist es das Prinzip der Entität zu verfolgen. Jeder Record (Entität) steht für eine einmalige Sache eines bestimmten Typs (Tabelle). Das bedeutet auch, daß zwei stadtteile in verschiedenen Orten auch zwei Entitäten in der Tabelle Stadtteil sein sollen.
Kurz, eine vernünftige Planung und Architektur einer relationalen Datenbank erspart später erhöhten Wartungsaufwand, steigert die Performance, verhindert Redundanzen (obwohl diese in seltenen Fällen sogar erwünscht sind) und Inkosistenzen.
Ja, aber über das Ziel hinaus schießen ist ebenso unvernünftig. Normalisieren auf 'Teufel komm raus' kann auch ganz schön nach hinten losgehen.
Deshalb sind in diesem Falle zwei Tabellen die bessere Wahl. Eine für die Stadt und eine für die Stadtteile.
Grüße
Klaus