Сенсей
Новичок
Всем привет.
Пишу сайта-каталог бизнессов. Нужно организовать удобный "специфический" поиск по сайту. Искать будут все таки не что попало, а то что конкретно человек ищет и знает чего хочет. Это или название услуг (например: перевод денег), или сфера деятельности (например: текстиль) и т.д. Исходим из того что все фразы и слова для поиска заранее известны. И их очень много.
Таблица разделов:
Таблица связей бизнесс = раздел (один ко многим)
Вложенность категорий всегда одна: На пальцах:
Категория | id=1 | Финановые услуги | parent_id = 0 |
Категория | id=2 | Банки | parent_id = 1 |
Категория | id=3 | Аудит и налоги | parent_id = 1 |
Категория | id=4 | Инвестиции | parent_id = 1 |
Категория | id=5 | Образование | parent_id = 0 |
Категория | id=6 | Школы | parent_id = 5 |
Категория | id=7 | Колледжи | parent_id = 5 |
Когда добавляем новый бизнесс в каталог - то к бизнесу можно прикрепить максимум 3 разных подкатегории. Бизнес не может быть прикреплен к категории которая является "папой".
Кроме это есть еще 3 таблицы с опциями которые заранее прикреплены к подкатегориям. При добавлении бизнесса в определенную под категорию - выбираются опции этой категории и дается возможность прикрепить эти опции к бизнессу.
Например при добавлении в подкатегорию Школы можно прикрепить к бизнессу опции: вечерняя, платная, имеется столовая, есть стоянка.
Все это опять же в отдельных таблицах и таблицах связей.
Все работае как часы пока дело не доходит до поиска. По идее это поиск заренее известных и специфических запросов.
Сейчас работает это так:
Вот так выглядят категории на сайте (не важно что там написано
1. Если юзер нажимает на парент категорию, с базы вытаскиваю все id детей) (так как связать парент категорию с бизнессом не даю) ... и потом выбираю уже все бизнессы связанные с этими id, ну и там GROUP BY и т.д.
2. Если юзер нажал сразу на подкатегорию - выбираю бизнесы которые соеденины с этим id.
Теперь со стороны поиска:
1. Юзер ввел в поиск фразу которую ищет. В базе ищу категорию название которой совпадает с фразой которая введена в поиск и если найдена такая - вытаскиваю id категории. Далее все работает по 2 пунктам которые описал выше. Добавлю что название парент категории никогда не совпадает с названием одной из подкатегорий.
Проблема: Что если пользователь ввел в поиск: "годовой налоговый отчет"?
ׂ*(Допустим еще что мне заранее известны все варианты запросов которые может ввести пользователь).
По идее я должен показать ему все бизнессы с подкатегории "Аудит и налоги". Так как по большому счету бизнесы которые там находятся выполняют эти услуги.
И вот тут дилемма.
1 вариант - отдельная таблица phrases с полем category_id - то есть один запрос привязан к конкретной категории и поиск выполняется по ней. Вытаскивам category_id и далее показываем все с этой категории. Можно расширить и сделать связь одной категории к нескольким фразам.
2 вариант - хранить все возможные фразы поиска для конкретной категории в поле text и обращать к fulltext search только в случае если не было найдено соответствий в названиях категорий или подкатегорий.
----
Еще в добавок если опции которые привязаны к самим бизнессам (поиск по ним тоже нужен).
И еще модераторы будут привязывать ключевые слова вручную к каждому бизнесу. По ним тоже нужен поиск.
Если делать по 1 способу - то это получается ужас от количества джоинов таблиц.
По идее я могу использовать привязку по id-ишникам опций тегов и всей этой фигни как обычно но не использовать для поиска... а для поиска просто собирать в "кучу" все опции теги и т.д. и кидать как plain text в текстовое поле и искать как fulltext-search. Юзеру то нафиг не надо знать если ему показывается результат который нашелся по совпадению в названии тега или в названии опции или в названии категории.
Не ищу кода или исходников. Интересует теория, может у кого опыт есть в этом. Может вообще другой подход существует.
З.Ы
Извините за много текста
Пишу сайта-каталог бизнессов. Нужно организовать удобный "специфический" поиск по сайту. Искать будут все таки не что попало, а то что конкретно человек ищет и знает чего хочет. Это или название услуг (например: перевод денег), или сфера деятельности (например: текстиль) и т.д. Исходим из того что все фразы и слова для поиска заранее известны. И их очень много.
Таблица разделов:
PHP:
CREATE TABLE categories (
id int(10) UNSIGNED AUTO_INCREMENT NOT NULL,
title varchar(100) NOT NULL,
parent_id int(10) UNSIGNED NOT NULL DEFAULT '0',
items int(10) UNSIGNED NOT NULL DEFAULT '0',
keywords text NOT NULL,
/* Keys */
PRIMARY KEY (id)
) ENGINE = MyISAM;
PHP:
CREATE TABLE business_categories_data (
id int(10) UNSIGNED AUTO_INCREMENT NOT NULL,
category_id int(10) UNSIGNED NOT NULL DEFAULT '0',
business_id int(10) UNSIGNED NOT NULL DEFAULT '0',
/* Keys */
PRIMARY KEY (id)
) ENGINE = MyISAM;Категория | id=1 | Финановые услуги | parent_id = 0 |
Категория | id=2 | Банки | parent_id = 1 |
Категория | id=3 | Аудит и налоги | parent_id = 1 |
Категория | id=4 | Инвестиции | parent_id = 1 |
Категория | id=5 | Образование | parent_id = 0 |
Категория | id=6 | Школы | parent_id = 5 |
Категория | id=7 | Колледжи | parent_id = 5 |
Когда добавляем новый бизнесс в каталог - то к бизнесу можно прикрепить максимум 3 разных подкатегории. Бизнес не может быть прикреплен к категории которая является "папой".
Кроме это есть еще 3 таблицы с опциями которые заранее прикреплены к подкатегориям. При добавлении бизнесса в определенную под категорию - выбираются опции этой категории и дается возможность прикрепить эти опции к бизнессу.
Например при добавлении в подкатегорию Школы можно прикрепить к бизнессу опции: вечерняя, платная, имеется столовая, есть стоянка.
Все это опять же в отдельных таблицах и таблицах связей.
Все работае как часы пока дело не доходит до поиска. По идее это поиск заренее известных и специфических запросов.
Сейчас работает это так:
Вот так выглядят категории на сайте (не важно что там написано
1. Если юзер нажимает на парент категорию, с базы вытаскиваю все id детей) (так как связать парент категорию с бизнессом не даю) ... и потом выбираю уже все бизнессы связанные с этими id, ну и там GROUP BY и т.д.
2. Если юзер нажал сразу на подкатегорию - выбираю бизнесы которые соеденины с этим id.
Теперь со стороны поиска:
1. Юзер ввел в поиск фразу которую ищет. В базе ищу категорию название которой совпадает с фразой которая введена в поиск и если найдена такая - вытаскиваю id категории. Далее все работает по 2 пунктам которые описал выше. Добавлю что название парент категории никогда не совпадает с названием одной из подкатегорий.
Проблема: Что если пользователь ввел в поиск: "годовой налоговый отчет"?
ׂ*(Допустим еще что мне заранее известны все варианты запросов которые может ввести пользователь).
По идее я должен показать ему все бизнессы с подкатегории "Аудит и налоги". Так как по большому счету бизнесы которые там находятся выполняют эти услуги.
И вот тут дилемма.
1 вариант - отдельная таблица phrases с полем category_id - то есть один запрос привязан к конкретной категории и поиск выполняется по ней. Вытаскивам category_id и далее показываем все с этой категории. Можно расширить и сделать связь одной категории к нескольким фразам.
2 вариант - хранить все возможные фразы поиска для конкретной категории в поле text и обращать к fulltext search только в случае если не было найдено соответствий в названиях категорий или подкатегорий.
----
Еще в добавок если опции которые привязаны к самим бизнессам (поиск по ним тоже нужен).
И еще модераторы будут привязывать ключевые слова вручную к каждому бизнесу. По ним тоже нужен поиск.
Если делать по 1 способу - то это получается ужас от количества джоинов таблиц.
По идее я могу использовать привязку по id-ишникам опций тегов и всей этой фигни как обычно но не использовать для поиска... а для поиска просто собирать в "кучу" все опции теги и т.д. и кидать как plain text в текстовое поле и искать как fulltext-search. Юзеру то нафиг не надо знать если ему показывается результат который нашелся по совпадению в названии тега или в названии опции или в названии категории.
Не ищу кода или исходников. Интересует теория, может у кого опыт есть в этом. Может вообще другой подход существует.
З.Ы
Извините за много текста