在MySQL中存儲距離

Question

我的數據庫中有一個「顏色」表。

用戶通過用戶界面輸入顏色，後端搜索顏色表中存在的最相似的顏色，計算HCL空間中顏色的距離。

我將實現一個緩存算法，它應該存儲以前計算的顏色距離之間的距離，以避免重複的數學運算。

什麼是這種目的的最佳表格佈局？

Answer 1

正如烏薩馬說，這看起來像過早的優化。根據您對算法的描述，我會：

• 預先計算數據庫中所有顏色的HCL向量，並存儲將顏色標識映射到其HCL向量的表。
• 該表應該使用MySQL Spatial Extensions進行存儲，它允許您查詢某個點的鄰居。
• 當選擇新顏色時，將其轉換爲HCL，並在HCL空間中查詢其點的鄰居。
• 如果需要緩存，我會緩存粗粒度的顏色，所以用戶有可能重新訪問以前選擇的顏色。

Answer 2

我對HCL不太熟悉，但基於Color::Similarity::HCL的描述，似乎需要兩種顏色作爲距離的輸入。

所以我會認爲至少有兩組RGB和它們之間的相應距離應該被存儲。我不確定你的使用情況，但是如果選擇了一系列選項，你也可以保存用戶選擇。

雖然似乎只有有限數量的組合？看起來你可以爲每個組合做一次數學計算，只需要一個查找表？

Answer 3

你可以這樣做：

table colors(r,g,b) 
table colordistance(user_r,user_g,user_b,r,g,b,distance) 

，但你希望你的用戶繼續輸入相同的數字???如果只包含最接近的顏色，則此表中的最大行數爲16777216。

我仍然懷疑數據庫訪問速度比計算慢，所以我在考慮引用「過早優化是所有邪惡的根源」。

我會運行它沒有任何緩存的計算，直到我看到它作爲一個實際問題。

Answer 4

我假設你的顏色「距離」的，就像這樣計算：

sqrt((r1-r2)^2 + (g1-g2)^2 + (b1-b2)^2) 

假設你使用的是8個像素，就在你的表（256^3）^ 2個不同的映射。這是很多表空間。 （您可能會壓縮它很多，但是...請參閱下一點。）

您需要考慮的另一件事是查找顏色距離與執行計算的成本的數據庫查找的成本。我的猜測是數據庫查找需要一毫秒或更多，但度量計算應該花費1微秒或更少。

總而言之，使用數據庫表對我來說聽起來真是個壞主意。

Answer 5

下面是我建議：

table colors(color_id, color_name, r, g, b) 

table color_distances(color_1_id, color_2_id, distance) 

指標： PRIMARY（color_1_id，color_2_id） INDEX（color_1_id，距離，color_2_id）

color_distances將包含所有可能的COLOR_ID組合，並且只會根據需要更新。然後

選擇是簡單的：