Выборка данных (а-ля умные фильтры)
Доброго дня. Необходимо решить задачу для создания структуры БД.
Пишу внутренний каталог. Хочу реализовать умные фильтры, разбитые по категориям. Например Цвет (Синий, Красный, Жёлтый), Умение (Пить, Курить, Колоться)...
Элемент БД может соответствовать нескольким фильтрам из категории. Например Цвет: Синий, Умеет: Пить и Курить.
Отвлекаясь пока от категорий фильтров, разобраться как выбрать из базы тех, кто одновременно умеет курить и пить.
Пытаюсь это сделать на таблице соответствий (как наименее ресурсоёмкой модели связей):
Есть таблица pf где pid - Элемент БД, fid - фильтр к нему:
pid | fid
2 | 3
2 | 5
2 | 8
3 | 5
3 | 8
4 | 8
Составляю вот такой запрос:
SELECT distinct pid FROM `pf` WHERE ( fid IN (5,8) )
С таким запросом он вынимает 2,3,4 (что логично).
Мне нужна логика, как вынуть только 2,3, которые в таблице соответствий в одному pid содержат fid и 5 и 8... А если только 8 - не вынимать...
В идеале - SQL-запрос.
Пишу внутренний каталог. Хочу реализовать умные фильтры, разбитые по категориям. Например Цвет (Синий, Красный, Жёлтый), Умение (Пить, Курить, Колоться)...
Элемент БД может соответствовать нескольким фильтрам из категории. Например Цвет: Синий, Умеет: Пить и Курить.
Отвлекаясь пока от категорий фильтров, разобраться как выбрать из базы тех, кто одновременно умеет курить и пить.
Пытаюсь это сделать на таблице соответствий (как наименее ресурсоёмкой модели связей):
Есть таблица pf где pid - Элемент БД, fid - фильтр к нему:
pid | fid
2 | 3
2 | 5
2 | 8
3 | 5
3 | 8
4 | 8
Составляю вот такой запрос:
SELECT distinct pid FROM `pf` WHERE ( fid IN (5,8) )
С таким запросом он вынимает 2,3,4 (что логично).
Мне нужна логика, как вынуть только 2,3, которые в таблице соответствий в одному pid содержат fid и 5 и 8... А если только 8 - не вынимать...
В идеале - SQL-запрос.
Заказ для наркодиспансера?
Я привёл для примера. Работа с цифрами.. они в приведённой таблице.
если количество параметров будет постоянным можно использовать set или битовые операции в условии
если количество параметров будет меняться редко можно для каждого параметра отдельный столбец добавить или хранить в текстовом массиве и искать по маске
если количество записей заранее неизвестно можно поиграться со структурами запроса (например сделать select * from table inner join table on inner join table on... или select * from (select * from( ... select*from table where1...) where2) where3))
если количество параметров будет меняться редко можно для каждого параметра отдельный столбец добавить или хранить в текстовом массиве и искать по маске
если количество записей заранее неизвестно можно поиграться со структурами запроса (например сделать select * from table inner join table on inner join table on... или select * from (select * from( ... select*from table where1...) where2) where3))
В том-то и дело, что количество параметров будет НЕПРЕДСКАЗУЕМЫМ...
Т.е. не должно от него зависеть...
В прошлом вопрос соответствия я решал лайками... Ну, например:
pid | filters
5 | :2::3::4::5::12:
И потом запрос был вида : SELECT `pid` from `PRODFILTERS` where (`filters` LIKE '%:2:%' AND (`filters` LIKE '%:12:%' OR `filters` LIKE '%:32:%'))
Т.е. по сути "вынуть все ПИДы, где Фильтры соответствуют 2 и (12 или 32)... Т.е. подходят с фильтрами 2,12 и 2,32...
Мне знающие люди сообщили, что LIKE - весьма "дорогая штука" для mysql...
Вопрос: На сколько дорогая, если учесть что всего таких записей будет не более 10.000, а реально (в работающей базе) не более 500... ???
Если такой подход (с Лайками) решает задачу таким образом, как нужно, допустимо ли его использовать???
Можно ли как-то это спроектировать проще и заставить работать с меньшими издержками?
Т.е. не должно от него зависеть...
В прошлом вопрос соответствия я решал лайками... Ну, например:
pid | filters
5 | :2::3::4::5::12:
И потом запрос был вида : SELECT `pid` from `PRODFILTERS` where (`filters` LIKE '%:2:%' AND (`filters` LIKE '%:12:%' OR `filters` LIKE '%:32:%'))
Т.е. по сути "вынуть все ПИДы, где Фильтры соответствуют 2 и (12 или 32)... Т.е. подходят с фильтрами 2,12 и 2,32...
Мне знающие люди сообщили, что LIKE - весьма "дорогая штука" для mysql...
Вопрос: На сколько дорогая, если учесть что всего таких записей будет не более 10.000, а реально (в работающей базе) не более 500... ???
Если такой подход (с Лайками) решает задачу таким образом, как нужно, допустимо ли его использовать???
Можно ли как-то это спроектировать проще и заставить работать с меньшими издержками?