У меня есть таблица цветов в моей базе данных.Хранение расстояний в MySQL
Пользователь вводит цвет через пользовательский интерфейс, а бэкэнд ищет наиболее похожий цвет, существующий в таблице цветов, вычисляя расстояние цветов в пространстве HCL.
Я реализую алгоритм кэширования, который должен хранить расстояние между ранее рассчитанными расстояниями цвета, чтобы избежать повторных математических операций.
Какова наилучшая схема таблицы для этой цели?
Как сказал Усама, это выглядит как преждевременная оптимизация. Основываясь на вашем описании алгоритма, я бы:
Я не слишком хорошо знаком с HCL, но, основываясь на описании на Color::Similarity::HCL, кажется, что в качестве входного сигнала для расстояния требуется два цвета.
Таким образом, я бы подумал, что должны храниться как минимум два набора RGB и соответствующее расстояние между ними. Я не уверен в вашем случае использования, но если выбран диапазон вариантов выбора, вы также можете сохранить выбор пользователя.
Кажется, что будет только конечное количество комбинаций? Кажется, вы могли бы сделать математику один раз для каждой комбинации и просто иметь таблицу поиска?
Вы неправильно поняли мой вопрос. Должен ли я помещать два color_ids и расстояние между ними в одной строке? или разместить расстояния и цвета в отдельном столе? – astropanic
вы могли бы сделать это:
table colors(r,g,b)
table colordistance(user_r,user_g,user_b,r,g,b,distance)
но вы ожидаете, чтобы пользователи продолжайте вводить одни и те же номера ??? Максимальное количество строк в этой таблице - 16777216, если вы включаете только самый близкий цвет.
Я все еще подозреваю, что доступ к базе данных медленнее, чем расчет, поэтому я думаю о цитате «преждевременная оптимизация - это корень всего зла».
Я бы запускал его без кэширования вычислений, пока не увижу его как актуальную проблему.
Я предполагаю, что ваш цвет «расстояния» рассчитывается как что-то вроде:
sqrt((r1-r2)^2 + (g1-g2)^2 + (b1-b2)^2)
Предполагая, что вы используете 8-битные пиксели, будет (256^3)^2 различных отображения в таблице. Это много места в таблице. (Вы могли бы, вероятно, сжать его много, но ... см. Следующий пункт.)
Другая вещь, которую вам нужно рассмотреть, - это стоимость поиска базы данных, чтобы найти расстояние по сравнению с затратами на выполнение расчета. Я предполагаю, что поиск базы данных займет миллисекунду или более, но расчет метрики должен занимать 1 микросекунду или меньше.
В целом, использование таблицы базы данных звучит как очень плохая идея для меня.
Вот что я рекомендую:
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 комбинации, и будет только обновляется по мере необходимости.
Выбор затем будет просто:
Как вы храните цвет? Как тройка целых чисел? Вы хотите кэшировать расстояние между расстояниями? Как бы вы определили это расстояние? Или просто кешировать расстояния между цветами? –
Цвет сохраняется следующим образом: [: id,: name,: red,: green,: blue] Расстояние - это десятичное число. Я буду кэшировать расстояния между цветами – astropanic
Каков ваш вклад в запрос? Если вы можете хранить данные, чтобы их можно было напрямую запросить с помощью ввода, это было бы самым простым решением. – Makis