Как извлечь из MySQL данные по нескольким критериям силами PHP?

Question

[Фёдор Ананин]

Доброго времени суток!
Пишу на PHP интернет-магазин, сейчас делаю фильтры для товаров. Допустим, заходите вы в салон Toyota и говорите "покажите мне белый Highlander". И вам показывают модель Highlander именно белого цвета.
В таблице с товарами есть ячейка filters, её содержимое - перечисление id фильтров через запятую. Допустим, для варианта "белый" соответствует id 1, а для "highlander" - 2. У белого хайлендера в filters будет написано "1,2". При этом, может быть и что-то вроде "1,2,3,4,5,6,7" - кто знает сколько разных фильтров будет у товара.

запрос к БД выглядит так:

$filters="[[:<:]]1[[:>:]] | [[:<:]]2[[:>:]]"; //пробелы для визуального разграничения - сливается
$query="SELECT * FROM table WHERE filters REGEXP '$filters'";

Этот запрос выводит все товары, которые имеют 1 в списке и все с 2 в списке. То есть, нам показываются все машины белого цвета и хайлендеры всех цветов.

Модернизация запроса до:

$filter=array(0 => "[[:<:]]1[[:>:]]", 1=>"[[:<:]]2[[:>:]]");
$query="SELECT * FROM table WHERE filters REGEXP '$filter[0]' AND filters REGEXP '$filter[1]'";

решает проблему... То есть, под каждый фильтр дописывается ещё один REGEXP... Если использовать не более двух-трёх фильтров при выборке, полагаю, нагрузка на mysql сервер будет в пределах нормы, но если таких regexp'ов будет 20-30-40?

Собственно вопрос: есть ли красивый выход из ситуации? Заранее спасибо.

Answer 1

[Viktor Vsk]

Серьезно. Вот Вы потратили 5, 10, 20, 100 часов что б реализовать вот это. Потом - время на написание вопроса. В конце еще написали

Собственно вопрос: есть ли красивый выход из ситуации?

То есть, в такой формулировке, вы предполагаете, что возможен вариант, что красивого выхода не существует (хотя, мне и сложно представить, каким бы был мир в таком случае)... И Вы даже не решили сначала, как это любят говорить менеджеры в наше время, проинвестигейтить этот вопрос? Действительно, Вам кажется, что может быть вариант, что, например, Ebay - имеет у себя пару петабайт регулярных выражений?

Я просто оставлю это здесь:
en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%...
zlob.in/2013/03/fasetnaya-poisk-v-internet-magazine

Comments

[Фёдор Ананин]

Огромное спасибо за ссылку на статью википедии. Я нашёл в ней разумный выход из своей ситуации. Касательно "проинвестигейтить"... Я до этого не слышал термина "фасетный поиск", поэтому гуглил запросы "php mysql регулярные выражения", так как полагал, что решение кроется именно в регулярке.

А в остальном, полагаю, этот сервис был придуман для того, чтобы люди решившие проблему, помогали людям только столкнувшимися с ней. Как оказалось, красивого выхода с регуляркой и нет :) Но он кроется в другом.

Поэтому, ещё раз огромное человеческое спасибо за наводку!

[Viktor Vsk]

Фёдор Ананин: не за что. Возьмите сначала за правило считать, что 99% проблем,с которыми Вы сталкиваетесь - уже решены миллион раз. После этого, оглянитесь вокруг и поищите похожую проблему (в конкретном случае, пускай это будет Яндекс.Маркет). Попробуйте масштабировать свое решение до уровня "цели". Если кажется, что это ну оооооочень сложно, пересмотрите подход и повторите.

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

[Фёдор Ананин]

Виктор Выскребенцев: Это решение тянется уже очень давно, ещё с написанного за ночь блога :) у заметки есть поле tags, где через запятую прописаны теги, а затем через LIKE я просто получаю список заметок, которые принадлежат определённому тегу. Задача простая, мультитеговость там не нужна. И да, это получилось плохое решение, но основанное на своём опыте.

[FanatPHP]

Вторая ссылка - какой-то треш. Аффтар описывает проблему и... всё. Пара невнятных ссылок, которых он - 100% не читал. Типичный дорвей, бессмысленный и беспощадный. Фу таким быть.

[Фёдор Ананин]

FanatPHP: Простите, а что я должен был ещё описать? Первая ссылка мне реально помогла, если она не помогла вам - увы. Вторая ссылка помогла понять как же эта технология называется.

[FanatPHP]

Читать научись. Я про того автора пишу, а не про твою супер-важную персону. А с понтом сочувствовать будешь себе, в скором времени.

[Viktor Vsk]

FanatPHP: зачем начинать новый разговор, если на предыдущем слился?)

Answer 2

[Shaks]

Я не побоюсь выразить наверное то, что крутится у многих на языке, кто прочел это) - Это пиздец, дружище ) Большой, кромешный пиздец )
Выход из ситуации. - nosql. Забудь про Мускул. Сделай все на mongodb например. Все данные хранить в древовидных коллекциях. Вобщем почитай, как раз все твои проблемы решаться оч легко и изящно.

NoSql позволит тебе в одной коллекции (аля таблице) хранить как автомобили с их характеристиками, так и туалетную бумагу, домашних животных и разные сорта вятского кваса.

Upd А по сабжу, если уж на мускуле делать, то нужно делать через связи has_many и/или has_and_belongs_to_many/has_many through, а не лепить айди через запятую и искать регулярками.

Т.е. есть таблица товаров. Есть таблица фильтров, и есть соединяющая таблица товаров и фильтров.
У каждого товара есть id, у каждого фильтра есть id, а в соединяющей таблице пишутся id'ы товаров и фильтров. Таким образом ты получишь нужную тебе связь.
Если ты чувствуешь что делаешь чтото не так, то скорей всего так оно и есть :) С таким подходом как у тебя, теряется вся логическая цепочка, мускул сойдет с ума, ибо не будет ведать что он творит )

Comments

[Viktor Vsk]

Конечно, называется это имнено так. Но выход, безусловно, совсем не nosql

[Shaks]

Виктор Выскребенцев: Я не буду особо вступать в полемику, т.к. не было практики у меня с фасетным поиском, но работа со сфинксом мне пока только грозит, но я еще не вникал в него. Собственно.. почему же безусловно? ) nosql идеально подходит под описанную ситуацию. И я не вижу ни одного минуса в этом. Про хайлоад и селекты мы ессно говорить щас не будем )

[Viktor Vsk]

Shaks:
1. Интернет-магазин (да и фильтры в частности) - типичная, давно решенная задача. nosql - нишевое решение
2. Даже если и появятся специфические условия (хоть и маловероятно), автору перед nosql нужно знакомиться со стандартными методами шерения.
3. С учетом того, что количество фильтров - ограничено (у каждой машины фильтр "цвет" представляет одно и то же) - будет большое дублирование информации.

[Фёдор Ананин]

Я слышал про nosql... Один знакомый программист постоянно упрекает меня за использование MySQL... Но пока 99% мои задач решаются мускулом, не вижу смысла уходить. В любом случае, спасибо за совет на будущее. Ваш upd полностью совпал с моим виденьем ситуации после прочтения совета от товарища Виктора. Сделать отдельную таблицу и уже в ней задавать соответствия. Спасибо.

Answer 3

[FanatPHP]

Следует понимать, что EAV - не панацея, а несколько наоборот - постоянная боль пониже спины.
Во-первых, если в реляционной модели за целостностью данных может следить СУБД, то здесь вся работа ложится на программиста.
А уж получив в том же EAV хотя бы пару-тройку уровней вложенности, можно начинать заранее строить себе стену, об которую потом захочется убиться.

А во-вторых, проблему поиска EAV не решает от слова "совсем". Искать надо другими средствами, например - сфинксом.
И вот тут на первый план выходит не удобство хранения, а удобство построения RT индекса. От которого и надо плясать.

Answer 4

[Глюкъ Виртуален]

Вы замучаетесь поддерживать и развивать эту колбасу с баянами уже через полгода.
Возьмите готовый бесплатный движок интернет-магазина. Практически в любом есть то что вам нужно.

Comments

[Фёдор Ананин]

С удовольствием, но в моём случае принципиально должна быть самописка.