007
14.06.2016, 13:48 Uhr
ao
(Operator)
|
| Zitat von Kaffeebart: |
Genau so war es gedacht. Ein zusätzlicher Eintrag pro Stadt indem ich direkt die Einwohner im gewünschtem Umkreis eintrage.
|
Nein, denn diese Zahl ändert sich täglich durch Geburten, Sterbefälle, Umzüge und evtl. anderes. Du müsstest jede Nacht die ganze Datenbank aktualisieren.
Du brauchst die Liste der Städte im Umkreis, die hat höchstens eine Handvoll Einträge, und die Einwohner im Umkreis ermittelst du auf Anfrage durch Aufaddieren.
Und wenn eine Stadt dazukommt oder aufgelöst wird, dann ändern sich halt die Umkreis-Listen aller umliegenden Städte. Aber selbst das ist ne übersichtliche Geschichte, und es passiert vermutlich nur selten.
Es könnte auch helfen, die Städte erst mal ganz grob zu klassifizieren und "Bezirke" zu definieren, sagen wir, 1000 Kilometer im Durchmesser und ein Stück überlappend, damit du keine Orte am Rand verlierst. Um die Umkreis-Liste für die Stadt XY zu bilden, musst du dann nur noch den Bezirk abgrasen, dessen Mittelpunkt nahe an XY liegt, und nicht mehr die ganze Erde.
Oder: Orte, die nach Längen- oder Breitengrad nicht in Frage kommen, gleich auszusortieren und den exakten Abstand erst gar nicht zu berechnen - was interessieren dich Orte in Australien oder Russland, wenn du die Umgebung von Hamburg brauchst?
| Zitat: |
Deswegen habe ich dennoch initial einmal den enormen Aufwand das für jed Stadt durch zu rechnen.
|
Stimmt. Darum sagte ich, denk vorher drüber nach, welche Anfragen du an die Datenbank stellen wirst, und optimiere die Struktur, so dass du später das Leben einfacher hast. Beispiel: Einführung der Umkreis-Listen.
Das ist bei Datenbanken oft so, dass sie im Originalzustand nicht so strukturiert sind wie man sie tatsächlich braucht. Das sollte man analysieren und Abhilfe schaffen, bevor der Kram in Betrieb geht, sonst wird man zeitlebens mit schlechter Performance bestraft.
Und wenn du das alles bedacht und geplant hast, dann machst du genau einmal die initiale Aufbereitung der Datenbank, und dann soll das doch lange dauern, wenn es will.
| Zitat: |
Ist bereits geschehen (siehe weiter oben im 2. Beitrag von mir. Wurde mit PHP geschrieben) .. nach irgendwas um die 3 Wochen Dauerrechnen habe ich etwa 150 - 200 Tausend Städte berechnet. - Daher ist meine Hoffnung, dass man in C doch eine bessere Performance hin bekommt.
|
Hoffnung ist aber kein gutes Prinzip beim Programmieren. Geh der Sache nach: Warum war die Performance so schlecht? Wo ist die Rechenzeit geblieben? Sind die DB-Zugriffe langsam? Oder die Mathematik? Lief das auf dem Server im Internet, auf dem dir nur ein bestimmtes Kontingent Rechenzeit gehört weil du ihn mit X anderen Kunden teilst?
Aus dem Bauch heraus sagen "ich probiers mal in C" ist jedenfalls kein guter Ansatz, wenn du dafür erst mal ne lange Lernkurve (C, C++, ODBC) vor dir hast.
Dieser Post wurde am 14.06.2016 um 13:56 Uhr von ao editiert. |
