在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组合，并且只会根据需要更新。然后

选择是简单的：