Aus dem verlinkten Artikel:
<zitat>Da die Abfrage durch die berechneten Felder stets einen full table walk verursacht, ist es eine Überlegung wert, die Entfernungen aller Postleitzahl-Koordinaten zueinander zu berechnen und in einer eigenen Tabelle zu speichern. Andererseits hat die Tabelle nur knapp 18.000 Zeilen; eine Tabelle, die naiv die Entfernungen aller Datensätze zueinander speicherte, beliefe sich auf knapp 324 Millionen Zeilen.</zitat>
Ich wundere mich, wie schnell die Umkreissuche bei MySQL funktioniert. Auch im verlinkten Beispiel sind die gesuchten Orte im Umkreis von 10 km in 0,04 s gefunden.
Da erübrigt sich die Extra-Tabelle mit den 324 Mio Einträgen. Und wenn, würde ich sie nach Bedarf aufbauen. Also mit Musterhausen als Zentrum in die Extra-Tabelle gehen. Falls Musterhausen noch nicht eingetragen ist, die gesuchten Orte mit ihren Entfernungen ermitteln und eintragen. Bei 10 km .. 50 km ist das ein überschaubarer Aufwand.
Felder: ort1_id
, distanz_km
, ort2_id
UNIQUE Keys: ort1_ort2
, ort2_ort1
Falls später größere Entfernungen zugelassen werden, ist die Tabelle zu ergänzen. Aber als Umkreis von Flensburg dürfte München NIE gefragt sein, also keine Panik vor der theoretischen Satzanzahl.
Linuchs
<edit>Hinweis: So eine Ortstabelle ist nicht statisch. Immer wieder gruppieren sich Orte neu, erfinden einen neuen Namen und haben dann eine neue geografische "Mitte", manchmal im Wald oder in einem See.
Ich würde der Extra-Tabelle noch das Feld last_modified
spendieren, um nach einem bestimmten Zeitraum (ein Jahr?) die Umkreisorte neu zu ermitteln.</edit>