這些會更安全/更好地運行？

我有451座城市座標。現在我想計算每個城市之間的距離，然後按照這個距離排列一些結果。現在我有2個選項：這些會更安全/更好地運行？

我可以運行一個循環來計算每個可能的城市組合的距離並將它們存儲到一個表中，這將導致大約200k行。
或者，我可以不經預先計算就離開城市，然後顯示結果（每頁大約30個），然後分別計算每個城市的距離。

我不知道哪個會更好，但我寧願選擇一個，在這種情況下，我有另一個擔心：有沒有辦法讓我儘可能少出行？目前，我認爲可能性爲451^2，但我認爲我可以將其除以2，因爲City1-City2的距離與City2-City1相同。

感謝

來源

2011-10-27 ItsGreg

如果您想知道哪個性能更好，請嘗試一下。拿出示例數據和一些可以運行的查詢，並針對每個選項嘗試它們。比猜測好得多。 –

我不是在猜測。我只是想看看是否有任何證明可以更快速地工作/減輕負擔。 – ItsGreg

我明白。儘管從問題的角度來看，兩者都應該合理快速地實施。但是，如果城市列表是靜態的，@ Ivan的答案是有道理的。 –

如果你的城市的表是或多或少是靜態的，那麼你一定要每個計算所有的距離，並將它們存儲在單獨的表。在這種情況下，你將有（451^2/2）行（只要確保City1的id始終低於City2的id（或者其他方式，並不重要））。

來源

2011-10-27 13:38:58 Ivan

-1

通常，單個MySQL查詢的成本非常高，數學運算的成本非常低。特別是如果你的地圖比例很小並且所需的精度很低，那麼你可以用一個固定的度數計算距離，計算起來會更快。

此外，如果由於項目發生變化而導致城市數量增加，並且因此您必須在數據庫中存儲的組合數超過限制，則會出現問題。

所以你可能會更好，沒有預先計算。

來源

2011-10-27 14:06:43 Beat

MySQL不會對錶格大小進行人爲限制，所以組合數量不會成爲問題。此外，OP似乎只是想根據距離返回記錄，這對於數據庫來說是微不足道的（例如：按距離升序排序，限制爲5）。最後，城市座標不會經常變化，所以預先計算的距離實際上可以節省處理時間。精確度可以在MySQL中修復。由於OP將會進行SQL查詢，因此SQL查詢的成本並不是真正的重要問題。 –

這些會更安全/更好地運行？

回答

相關問題