30 июня 2019 в 20:41
А чем фацетный поиск принципиально отличается от просто view с большим количеством раскрытых фильтров?
Главные вкладки
30 июня 2019 в 20:41
Комментарии
Простотой.
Клик-клик и в продакшн.
Принципиально - всем. Разные подходы, разные алгоритмы, разные источники данных (вероятно, даже, разное назначение).
Для фасетного поиска используется специально подготовленный индекс, обычные же фильтры представлений используют "голые" ("raw") данные из БД.
Если очень коротко - раскрытые фильтры подправляют запрос, в соответствии с введенными данными, а фасетные фильтры предоставляют вхождения для фильтрации, относительно текущей позиции выборки данных, и позволяет далее корректировать выборку по существующим вариациям.
Тут можно немного почитать. Ну и погуглить дальше, если интересно как все внутри работает.
А я вижу больше сходств чем различий. Понятно, что "под капотом" разные источники данных, но для пользователя выглядит совершенно одинаково - множество фильтров по заданным атрибутам, позволяющих сузить выборку. Не вижу принципиальных противоречий между
и
Я могу понять зачем строить "специально подготовленный индекс" для текстовых полей/статей, где нужен быстрый поиск по ключевым словам, да ещё с учётом словоформ/падежей. Но не могу понять зачем его строить по полям "типу товара, марке, цене" (© wiki) - по этим полям уже есть вполне годные индексы в основной БД, если конечно ее проектировал не полный олигофрен.
У меня в базе практически нет текстов - только названия, имена, адреса, теги, перекрестные ссылки. Я уже готовился осваивать фацеты и вдруг понял, что не понимаю зачем они мне нужны, когда я могу всё что мне нужно реализовать на простых вьюхах. Поэтому и решил посоветоваться с более продвинутыми товарищами.
В целом, все верно: если не нужен именно фасетный поиск - значит он не нужен.
Разница в том, что фасеты позволяют сделать выборку по только пересекающимся значениям, а обычные фильтры - просто выбирают информацию согласно введенным данным.
Вот картинка с вики, которая признана для визуальной передачи различий:
Еще раз, фасеты - это поиск постепенными уточнениями, обычные фильтры представлений - фильтрация условий выборки (читать добавление условий "WHERE *").
Еще раз спасибо за терпение, но всё равно не очень понятно.
Сравнивать с "навигационным поиском" некорректно - я же не его предлагаю.
Возьмем пример прямо из вики - есть тип материала "товар", у него три поля: тип товара, марка, цена. Если верить вики - это классический случай для фасетов.
Я создаю вью по товарам с тремя раскрытыми множественными фильтрами - тип товара, марка, цена. В отображаемых полях товара вывожу еще и картинку.
Пользователь может выбрать в первом фильтре "телевизор", во втором "Philips, Sony", в третьем "< 50000р" и получить список товаров, удовлетворяющим заданным условиям.
Если то же самое сделать на фасетах, какие дополнительные плюшки получу я как разработчик и мой пользователь?
И, кстати, картинки в выводе легко будет добавить? Когда читал по диагонали документацию по фасетам, там что-то такое было написано, что поля можно выбирать только из серч-индекса, а там картинка вряд ли окажется.
Так добавление условий WHERE и есть способ постепенного уточнения.
При фасетном поиске будет немного другой шаблон поведения:
От: [10,099] до [50,489]
От: [21,548] до [35,999]
От: [30,099] до [30,099]
Кажется понял - принципиальная разница в том, что при каждом клике динамически перестраиваются и доступные фильтры, и отобранные товары. То есть главная разница по сути - в динамике UI.
Если смотреть с т.з. UI, то да.
Но, для меня лично, главная разница в реализации поиска. На самом деле, можно наколхозить такую динамику и обычными фильтрами представлений, даже модули есть. Просто нужно понимать, что для получения относительно того же результата, нужно будет каждый раз проделывать приблизительно следующее:
И все это, проецируя на нашу много-джойновую систему хранения данных в Друпал, может давать весьма значительные оверлоады, вплоть до превышений времени загрузки, не говоря уже о скорости работы таких фильтров, на хоть сколько серьезно заполненной БД.
А фасеты, по индексу, сразу получают выборку кроссов, а при выносе в специализированные хранилища - еще и дают неплохой буст.
Вообще, лучше от задачи плясать, а не лепить фасеты или фильтры от балды.
Обычно, ради этого фасеты ставят:
https://www.drupal.org/project/facetapi_pretty_paths
https://www.drupal.org/project/facets_pretty_paths
P.S. https://drupal.ru/node/139370
Во-первых, про индекс в корне неверно. Обычные раскрытые фильтры можно сделать и на Search API индексе.
Фасетный поиск сам по себе - это сужающаяся выборка, в которой возможные значения фильтра зависят от уже имеющихся результатов выборки. Это независимо от друпала, а вообще. То есть в двух словах, если есть фильтры по бренду и ОС, то при клике на эппл фильтр "андроид" пропадёт, не дав накликать критерии с нулевой выборкой.
Что касается фасетного поиска конкретно на друпале: очень важно понимать, что фасетные фильтры - это ссылки, а не форма. Поэтому после каждого клика по фильтрам идёт загрузка новых результатов.
Но я же в принципе могу это и на раскрытых фильтрах намутить - ограничить список доступных городов выбранной страной, если есть очевидная связь город->страна? Или тогда мои раскрытые фильтры превратятся в фасеты?
Это существенно, да.
Связь не всегда так однозначна. Например, бренд/диагональ экрана/цена и т.д. Пользователь может очень долго и вдумчиво задавать значения фильтра, а потом нажмёт применить и получит пустую выборку, потому что выберет параметры "эппл на андроиде ценой до 200$". С фасетами же такая ситуация невозможна в принципе.
Ага, понял, спасибо!
Э, не... Это представление по индексу, что не есть "просто view с большим количеством раскрытых фильтров".
ЗЫ: Когда форма - тоже, каждый раз новая выборка и новые результаты. Данные фильтров - также, гетами формируются в урле. Ссылки вместо формы - исключительно условность реализации в друпал. Формами так же можно, просто париться больше чтоб правильный биндинг сабмитов настроить при работе на клиенте (в JS) и косяков не огребать с каждой темой.
Представление по индексу - это тоже представление и раскрытые фильтры в представлении по индексу ничем не отличаются от таковых в любом другом представлении. Более того, ничто не мешает использовать раскрытые фильтры и фасеты одновременно.
Что касается формы - она всегда одна, если это не selective filters. Если есть магазин, где 50 товарных групп и 200 критериев фильтрации, то раскрытая форма как раз не подходит из-за того, что она всегда будет показывать 200 критериев. А фасеты будут показываться только те, что есть в текущей выборке.
Ну, как не отличаются
Давай разбираться что мы вкладываем в понятие "представление"...
Если это ГУЙня для накликивания списков отображаемых сущностей - то да, ничем не отличаются, вроде как. И здесь можно собрать, и тут.
Если это про принципы хранения и выборки данных для отображения - то отличаются, как раз тем что представления по индексу использует этот самый индекс (сорри за туфту) для выборки, а не тупо таблицы сущностей под которые настроены. Я представлял с этой стороны, т.к. вопрос был о принципиальных различиях, не думаю что ТС имел цель узнать различия в сборке представления из админки для вьюх по индексу и без.
И да, ничего не мешает вместе, и я думаю что не о том мы спор ведем, на самом деле
Моя реплика была касательно того что ".. про индекс в корне неверно", в то время когда именно в индексе и есть различие между выборкой для фильтров обычных представлений (которые не по индексу), и для фасетов (которые используют тот самый индекс). И для этого я писал о нем (индексе).
А про пересечение критериев я чуть выше отписал ТСу. ИМО.
Search API views - это всего лишь несколько плагинов для вьюса. Можно написать плагин для выборки вьюсом данных, скажем, из экселевской таблицы. От этого вьюс вюсом быть не перестанет.
Я не утверждаю обратного.
Всем спасибо - очень познавательно!
Ну по сути получается, фасеты это
более юзерфрендли интерфейсы (меню вместо селектов-чекбоксов и т.п.)
+ индекс
+ текущее кол-во элементов в выборке для каждого доступного "критерия-фильтра"
и прочие аяксы.
Что там, что там условия выборки обычно(если не настроено иначе): ИЛИ в пределах терминов одного словаря, И - в пределах словарей, участвующих в выборке.
Нет.
Юзабилити скорость удобство