Задача: пользователь заходит на сайт с обоями для Windows.
В каталоге представлены обои на следующие тематики:
*Горы
*Леса
*Автомобили
*Дома
При этом обои могут одновременно относиться как к одной, так и к двум темам:
*Горные пики (тема: горы)
*Предгорье (тема: горы, леса)
*Домик в деревне (тема: дома)
*Вилла и лимузин (тема: дома, автомобили)
В строке поиска клиент выбирает, например, такие теги: дома, автомобили. Должны быть показаны обои, на которых фигурируют и дома, и автомобили одновременно.
Предполагается, что база обоев будет постоянно расширяться. Будут добавляться все новые и новые темы. Поиск можно будет осуществлять и по 2-м и по 10-ти тегам (кому как понравится).
Если я не ошибаюсь, то в БД хранятся ссылки на изображения. Сами изображения хранятся в файловой системе. Вопрос по тегам: в каком виде их хранить? Пока рассматриваются следующие варианты:
1 - Список тегов в столбце в виде одной строчки с разделителями (например, дома|автомобили). При поиске строка расщепляется в массив (array(дома, автомобили) и осуществляется проверка массива. В качестве недостатка вижу издержки на соединение/расщепление единой строчки. А также, возможно, недостатком является то, что поиск ведется не только средствами БД, но и с помощью языка (PHP). Какая-то двойственность получается. Еще один вариант - сериализовать строчку тегов.
2 - Создать таблицу тегов (tag_id, tag_name) и изображений (img_id, img_name). А также сделать промежуточную таблицу, состоящую иp tag_id img_id. По этой промежуточной таблице осуществлять поиск img_id, для которых назначен искомый tag_id.
Оба решения имеются в интернете. Пока склоняюсь ко 2-му варианту.
Может быть, существует и третий (и четвертый) варианты, оптимальные для данной задачи?
Буду благодарен за любые подсказки!
З.Ы. Задача с обоями придумана для наглядного описания задачи.
1. Вариант съест много памяти и заработает только в случае если искать сторонним сервисом, поиск с помощью like - зло, на 5 запросах в минуту может и потянет, да и то зависит от объемов бд.
2. Уже правильно, один минус, сложно искать пересечения, запросы будут тяжеловаты. Не будет полнотекстового поиска (хотя зависит от бд)
3. Использовать сторонний сервис, например sphinx, даст полнотекстовый поиск, например по тайтлам, даст поиск по тагам (multi-value аттрибуты), даст возможности по управлению ранжированием и т.д. Как вариант можете посмотреть в сторону lucene, но с ним общаться не приходилось.
Лучше копайте в сторону 3го решения, не так оно сложно, как пытается выглядеть.
AxisPod, в случае 3-го решения возникает 3-я сторона в виде сервиса. Велики ли издержки, например, по производительности, из-за ее наличия? А также появляется зависимость от этого сервиса. Насколько они надежны?
Средний
