MySQL Запрос / Сортировка

Что значит "сортировку по релевантности таблицы" ?

Лучше опишите задачу, какие у вас есть данные (с примерами таблиц), и что вы хотите получить на выходе.

А вы за количество записей будете отдельно оплачивать?

В таблице цветов возможно сделать 10 столбцов с цветами на каждый айдишник.

Есть таблица, в который есть столбцы id и colors. В столбце colors через запятую указывается 10 цветов ( например 000000,333333,000033,330000,663333,330033,333366,666666,999999,996666). Задача: при поиске по одному цвету нужно отсортировать результат в порядке уменьшения количества цвета (это подразумевалось под "релевантностью") с помощью второй таблицы в которой будет храниться id записи из первой таблицы, цвет и количество цвета. Вопрос: как должна выглядеть вторая таблица?

---------- Добавлено 16.10.2014 в 18:13 ----------

Как в таком случае организовать сортировку?

А как определяется "количество цвета"?

Если вы при добавлении изображений берёте его основные цвета и добавляете в базу, то зелёный цвет будет только один.

Т.е. он или есть или нет.

Если же вы хотите сделать поиск изображений по цвету, например, "хочу найти изображения с зелёным цветом", и вам сначала выдаются изображения, в которых больше всего зелёного, а потом всё меньше и меньше, то тут вообще нужно делать всё по-другому.

Именно так. Количество цвета определяется на PHP и заносится в массив, пример которого я дал в стартовом посте. Жду ваших предложений)

Предлагаю сделать таблицу images_colors с четырьмя столбцами id, image_id, color, color_weight и по ней уже делать поиск и сортировку.

В таком случае на одну запись в первой таблице придется 10 записей в другой, это много)

Если бы цвет был один, тогда и вопросов нет

Всё. Наконец-то допетрил, как у вас считается :)

Вобщем, если вы хотите искать по общему (среднему) цвету всего изображения, то берёте, считаете этот усреднённый цвет, и сохраняете в базе в виде десятичных чисел (r,g,b). Прям в той же таблице, что и сами изображения.

(r,g,b) — это у нас вектор.

И мы можем сделать поиск изображений, похожих по среднему цвету на какой-то заданный, вычисляя расстояние между вектором заданного цвета и цвета изображения.

Отсортировав по этому расстоянию, сначала получим изображения, наиболее близкие к заданному цвету.

Минус тут в том, что никакие индексы БД задействовать не получится и при каждом поиске будет происходить полный перебор.

Если же вы хотите искать не по одному среднему цвету изображения, а по нескольким, то действуем аналогично. Определяем несколько самых "популярных" цветов у изображения и записываем их в базу в дополнительную таблицу (ID, r, g, b, c). Где "c" — какой-то показатель количества, и на этот "c", например, делим вычисленное расстояние. Ну или ещё как-то его используем в вычислениях, чтобы улучшить результат.

---------- Добавлено 16.10.2014 в 19:31 ----------

В этом большой проблемы нет.

Если нужно хранить несколько цветов, то для каждого их них понадобится дополнительная ячейка (три ячейки).

И они будут либо в дополнительной таблице, в виде отдельной строки, либо в одной строке в общей таблице (ID, filename, ... ,r1,g1,b1, r2,g2,b2, r3,g3,b3, ...)

Только в первом случае есть возможность для экономии, если у одного изображения есть только три основных цвета, а у другого их десять.

Не в качестве совета, а в качестве ответа на твой же вопрос:

ID | color1 | color2 |.... (цвета же определены и их 10)

_____________________________________________________

1 | 35 | 18 | .......

и сортируй как хочешь