ChrisB: Laufzeit mit Entfernungstabelle verkürzen?

Beitrag lesen

Hi,

Pro Programmlauf sind die hier genannten Werte

$rad_lon1 = deg2rad( $row_zentrum['geo_laenge'] ); // = 0.173359191277
$rad_lat1 = deg2rad( $row_zentrum['geo_breite'] ); // = 0.869112880969

konstant, aber beim nächsten Lauf (anderer Ausgangsort) sind sie anders.

Die mit diesen Werten berechneten SIN- und COS-Werte müssen nicht alle in der Query berechnet werden, sondern das kann PHP teilweise vorher schon einmalig machen.

Die einmal per UPDATE für alle Datensätze befüllt - dann braucht man nachher beim Auslesen der Daten nur noch diesen einen Spaltenwert auslesen, anstatt die Berechnung jedes Mal durchzuführen.

Das passt wohl nicht.

Zumindest die Bestandteile, in denen ort1.geo_breite/ort1.geo_laenge (direkt) vorkommen, ändern sich nicht, können also im Voraus berechnet werden.

Wenn du das machst, kannst du die eigentliche Berechnung innerhalb der Query von einem *Haufen* jedes Mal auszuwertender trigonometrischer Funktionen („teuer“!) auf ein paar Multiplikationen und Additionen „bekannter“, bereits vorliegender Werte plus je *einen* Aufruf von ACOS() und COS() herunterschrauben.

ROUND(  
  6366.19773095  
  *  
  ACOS( -- muss als Gesamtwert dynamisch berechnet werden  
    SIN(0.869112880969) -- vorher per PHP ermittelbar -> konstanter Wert  
    *  
    SIN(RADIANS(ort1.geo_breite)) -- vorher ermittelbar -> kann in extra Spalte liegen  
    +  
    COS(0.869112880969) -- vorher per PHP ermittelbar -> konstanter Wert  
    *  
    COS(RADIANS(ort1.geo_breite)) -- vorher ermittelbar -> kann in extra Spalte liegen  
    *  
    COS( -- muss als Gesamtwert dynamisch berechnet werden  
      RADIANS(ort1.geo_laenge) -- vorher ermittelbar -> kann in extra Spalte liegen  
      -  
      0.173359191277  
    )  
  )  
)

MfG ChrisB

--
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?