Ich habe ein Adressverwaltungsprogramm (DB ist mySQL), welches ich nun insofern erweitern soll, dass bei Eingabe der PLZ der Ort automatisch gefüllt werden soll.

Meine Recherchen bezüglich der Datenverfügbarkeit PLZ/Ort haben mich zu OpenGeoDB geführt. Doch irgendwie blicke ich da noch nicht so richtig durch.

- Macht es nun Sinn für mich, eine neue Datenbank für die OpenGeoDB auf meinem mySQL-Server anzulegen und einen Dump einzulesen? (Viele Daten von denen ich die meisten im Moment gar nicht brauche. Aber dann wäre ein Update der Daten einfacher?)
- Oder ziehe ich mir nur die Textdatei plz.tab (oder nur PLZ und Ort) in eine neue Tabelle meiner vorhandenen DB? (dann könnte ich die Daten nicht vernünftig updaten?)
- Oder gäbe es da auch eine Delphi-Komponente, die mir den Ort ausm Internet holt?

Sicherlich hat der ein oder andere von euch sich mit dem Thema schon mal auseinandergesetzt und kann mir dazu wertvolle Tipps geben.

Danke im Voraus

Hallo,

hab' mir die Datei PLZ.tab gerade mal angeschaut.

Würde hier eine eigene Tabelle in meiner DB anlegen und die Textdatei importieren.
Beim Update ein Truncate auf die eigene Datenbanktabelle und anschließend eine neue PLZ.tab einlesen. (Bei fremden Daten immer alles Eigene wegwerfen und vollständig neu einlesen. - Eine "eigene" Pflege der Tabelle PLZ.tab muss dann aber zwingend unterbleiben.)

Wenn die Tabelle dauerhaft unter http://fa-technik.adfc.de/code/opengeodb/PLZ.tab (oder wo sonst auch immer) zu erreichen sein sollte, ließe sich das Update per tIDHTTP... automatisieren.

Im Programm könnte man die "eigene" Datenbanktabelle für PLZ.tab als Nachschlagtabelle hinter das Postleitzahlenfeld legen.
Mit einer TDBLookupComboBox wäre das recht einfach zu lösen, man hat dann nach der Eingabe einer PLZ automatisch den Ort dazu.

Die PLZ.tab scheint aber keine Postfachpostleitzahlen zu enthalten, hier würde ein Nachschlagen daher nicht funktionieren. Wäre das bei Deinem Programm erforderlich?

Danke dir nahpets. Ja, deine vorgeschlagene Vorgehensweise war auch mein erster Gedanke. Aber ich weiß eben nicht, ob diese Datei immer dort zum download liegt und immer genau so heißt und immer dieselbe Struktur hat. Ist das UTF-8? Sieht in meinem Windows so komisch aus.

Zitat von nahpets:

Die PLZ.tab scheint aber keine Postfachpostleitzahlen zu enthalten, hier würde ein Nachschlagen daher nicht funktionieren. Wäre das bei Deinem Programm erforderlich?

Ah, das ist mir noch gar nicht aufgefallen, denke darauf kann ich aber auch verzichten.

Hallo,

das scheint kein UTF8 zu sein, sondern eine reine Textdatei, mein Editor kommt jedenfalls mit den Umlauten klar, also ein Windowszeichensatz.

Naja, ob die Datei immer da liegt und immer die gleiche Struktur haben wird und immer in der Struktur unverändert bleiben wird? Nix genaues weiß man nicht.

Eine eigene Datenbanktabelle hätte dann aber den Vorteil, Du könntest aus Daten einer anderen Quelle durch eine neue Importroutine Deine bisherige Tabelle befüllen und müsstest dann im Programm und im Datenbankschema nichts ändern. Außerdem müsstest Du dann nur die tatsächlich von die benötigten Daten einlesen, kannst also alle Spalten der PLZ.tab verwerfen, die Du nicht benötigst.

Beim Einlesen eines Dumps bekommst Du automatisch neue oder veränderte Strukturen und musst dann Programm und/oder Datenbankroutinen ändern und ggfls. alles ausliefern.

Eine veränderte Textdatei führt zu weniger Aufwand, da nur Einlesescripte bzw. Konvertierroutinen geändert werden müssen.

Hier ist eine weitere Quelle für die Tabelle http://www.manfrin-it.com/postleitzahlen/plz.html

Falls Du in einer anderen Quelle noch Postfachpostleitzahlen mit Orten finden solltest, könntest Du die Daten auch in einer Tabelle zusammenfügen, was bei einem Dump nicht möglich ist.

Bei mehreren Quellen in einer Datenbanktabelle könntest Du noch ein Feld "Quelle" in Deine Tabelle einfügen und dieses zusammen mit den Daten befüllen, dann kannst Du bei einem Update ein Delete from Tabelle where Quelle = 'Lieferant' machen und anschließend neu einlesen.

Vermutlich bist Du mit dem Einlesen von Textdateien auf Dauer flexibler, als mit dem Einlesen von Datenbankdumps und kannst mit weniger Aufwand auf "externe" Änderungen reagieren.

Bei einem Dump bist Du darauf angewiesen, dass er für "Deine" Datenbank zur Verfügung steht. Wenn Du nun (warum auch immer) von MySQL auf PostGres, Oracle, FireBird... wechselst, bekommst Du garantiert erstmal ein Problem, mit Einleseroutinen für Textdateien musst Du "nur" die Datenbankverbindung ändern und schon ist diese Aufgabe erledigt (ok, könnte ein bisserl mehr werden, aber sicherlich weniger, als nötigenfalls zwei Datenbanken zu unterstützen, eine für Deine Daten und eine für die Postleitzahldaten.)

Zitat von baumina:

Ist das UTF-8?

Zumindest Firefox sagt UTF-8. Sieht aus wie CSV mit Tabs als Trenner; ich denke nicht, dass die an der Struktur allzu-viel ändern.

Zitat von nahpets:

das scheint kein UTF8 zu sein, sondern eine reine Textdatei

Öhm ... UTF-8 ist eine Zeichencodierung, die in "reinen" Textdateien benutzt wird; normaler geht es kaum

Die flexibelste Lösung wäre es, wenn du die Daten in einem bestimmten Format auf deinem eigenen Server bereitstellst und damit die Herkunft der Daten einfach ändern kannst ohne den Klienten anzufassen.
Zudem könntest du Daten aus verschiedenen Quellen zusammenführen und die Server der Quellen würden entlastet.

Falls Du die GroßkundenPLZ benötigst, schau mal hier rein

Gruß
K-H

Hallo ,
@BUG

Zitat von BUG:

Zitat von nahpets:

das scheint kein UTF8 zu sein, sondern eine reine Textdatei

Öhm ... UTF-8 ist eine Zeichencodierung die in "reinen" Textdateien benutzt wird, normaler geht es kaum

Jaja, hast recht, habe mich (mal wieder) unpräzise ausgedrückt.
Ja, hast recht, ist UTF8, wußte garnicht, dass per Copy&Paste von Firefox nach Uralteditor konvertiert wird, ohne dass man das mitkriegt.

Reine Textdatei ist für mich sowas wie Zeichensatz für MS-Dos(e) oder Ansi

@baumina

Zitat von p80286:

Falls Du die GroßkundenPLZ benötigst, schau mal hier rein

Mit den hier genannten Quelle kannst Du Dir eine (fast) vollständige Nachschlagtabelle bauen, aus der PLZ.tab die Spalten 2 und 5, aus der plz_gross.txt die Spalten 1 und 2.
Die Grosskundentabelle der UNI-Mainz ist vom 01.12.1993, also nicht zwingend aktuell.

Hiermit bist Du mit einer eigenen Datenbanktabelle und eigenen Einleseroutinen flexibler als mit Datenbankdumps für die PLZ.tab...

Wir bedienen uns bei Oracle immer des SQL-Loaders. Die Quelldaten werden per FTP von verschiedenen Quellen gezogen und alles per Script verarbeitet.

Bei Änderung der Quelladresse muss nur die FTP-Verbindung geändert werden, bei Änderungen an der Datenstruktur werde die SQL-Loaderscripte geändert. In der Regel sind die Änderungen in wenigen Minuten erledigt und wir müssen nur die Daten übernehmen, die wir benötigen und nicht in episch gelieferter Breite.

Hallo,

solltest noch suchen...
http://www.datendieter.de/item/Postl...te_Deutschland

Zitat von nahpets:

Die Grosskundentabelle der UNI-Mainz ist vom 01.12.1993, also nicht zwingend aktuell.

Da die Beziehung zwischen PLZ und Ort gesucht wird, sollte es ausreichend sein. Soweit ich weiß gibt es für Großkunden und Postfächer feste Bereiche. Falls also die PLZ für die Wohnort Bestimmung genutzt werden soll, könnten sie ausreichen oder aber eine Warnung "keine echte PLZ" generieren. Je nach dem was man braucht. ggf. wäre es in der Vergleichstabelle sinnvoll einen Typen für die PLZ zu speichern 1=StraßenPLZ 2=Postfachplz 3=GroßkundenPLZ.

Gruß
K-H

Zitat von blondervolker:

Hallo,

solltest noch suchen...
http://www.datendieter.de/item/Postl...te_Deutschland

bisl sehr alt ..ich hab sowas mal gemacht vor paar Jahren ..wir hatten in der Firma als Quelle immer die Aktuelle CD http://www.deutschepost.de/dpag?xmlF...nk1015592_1041

Da gibts CSV Datei..einfach in eine Datenbank zu uebernehmen und vorallem AKTUELL