Straßen- und Ortsdatenbank trennen?

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Straßen- und Ortsdatenbank trennen?

    Hallo,

    aktuell besteht eine Ortsdatenbank nach dem Schema:

    ort_id;plz;ortname
    1;10115;berlin
    2;10117;berlin
    3;10119;berlin
    4;14467;potsdam
    5;14469;potsdam
    6;14471;potsdam
    7;14473;potsdam
    8;14478;potsdam
    9;14480;potsdam
    ...

    Gelistet sind also alle PLZ von Berlin + Potsdam.

    Nun sollen zu jeder PLZ auch noch die dazugehören Straßen erfasst werden.

    Variante 1 (extra Tabelle):

    strassen_id ; ort_id ; strasse
    1;2;Hauptmarkt
    ...

    Das wäre also z.B. dann der "Hauptmarkt" in 10117 Berlin.

    Variante 2 (alles in einer Tabelle):

    strassen_id ; plz ; ort ; strasse
    1;10115;Berlin;Brunnengasse
    2;10115;Berlin;Frankstraße
    3;10115;Berlin;Kanarienweg
    4;10117;Berlin;Hauptmarkt
    ...

    Zwei getrennte Tabellen machen die Abfragen für mich schwieriger dank JOINS

    Eine Tabelle ist aus Normalisierungssicht natürlich unpassend, aber die erfassen Daten werden eigentlich nicht mehr erweitert. Ich würde daher zu dieser Variante tendieren. Seht ihr da irgendwelche Nachteile?

  • #2
    Von welchem Umfang reden wir? Wenn weniger als 1000 DS dann Sch**ß auf die Normalisierung. Alles in einer Tabelle, ist schneller

    Kommentar


    • #3
      Sagen wir mal knapp 5000 Datensätze. Okay es fallen natürlich paar Bytes mehr in der DB an, aber ...

      Kommentar


      • #4
        Original geschrieben von Truncate
        Sagen wir mal knapp 5000 Datensätze. Okay es fallen natürlich paar Bytes mehr in der DB an, aber ...
        Das ist schon wieder zu viel. Denn der Pflegeaufwand ist zwischen 1000 und 5000 schon gewaltig

        Kommentar


        • #5
          Wiegesagt geändert wird an den Daten eher nichts mehr... es sei denn eine Straße kommt hinzu oder sonstwas ändert sich. Ist aber eher unwahrscheinlich.

          Ich dachte bei Problemen eher nur an eventuelle Abfrageprobleme die diese einzige Tabelle mit sich bringen könnte.... sprich das sie ev. unflexibel ist.

          Kommentar


          • #6
            Ich würde die normalisierte Variante nehmen, hier sind flexiblere Abfragen möglich. Außerdem gibt es die Normalisierung nicht umsonst und bei dieser Menge an Datensätzen kann man sogar noch Speicherplatz sparen.
            Die Regeln | rtfm | register_globals | strings | SQL-Injections | [COLOR=silver][[/COLOR][COLOR=royalblue]–[/COLOR][COLOR=silver]][/COLOR]

            Kommentar

            Lädt...
            X