2010-09-02 2 views
0

Получил веб-приложение в разработке; требование предоставить одно поле поиска, который осуществляет поиск важных полей в главной таблице, плюс других полей, связанные с помощью PK/FK из соединяемых таблицСтратегия поиска для нескольких полей в веб-приложении

схема выходит что-то вроде этого

PROJECTS 
projectID 
projectTitle 
projectTown 
projectCountryID (FK to countries table) 
agencyID (FK to agencies table) 

COUNTRIES 
countryID 
countryName 

AGENCIES 
agencyID 
agencyName 

TAGS_PROJECTS (many-many relationship between tags and projects) 
id 
projectID 
tagID 

TAGS 
tagID 
tagName 

Так пользователь должен ввести слово для поиска и мы хотим узнать, встречается ли оно в проектах project.projectTitle, projects.projectTown, countries.countryName, agency.agencyName или tags.tagName для любых тегов, назначенных для проекта.

Набор данных со временем будет расти, чтобы быть на порядка 10 000-50 000 строк в таблице проектов, а 000 в других таблицах

Я собираюсь создать испытательную установку и запустить тесты разных подходов, но я задавался вопросом, имел ли кто-либо ранее подобную ситуацию и предлагал ли какой-либо совет?

Возможных подходов я рассматриваю и испытаю являются:

SINGLE QUERY Я предполагаю, что это будет возможно, чтобы написать один запрос SQL для выполнения поиска, но такой запрос, вероятно, плохо работает без тщательной оптимизации как только данные выросли до полного размера. Проблема в том, что я не буду участвовать в запуске проекта, и поэтому не будет иметь полных реальных данных для экспериментов с

МНОЖЕСТВЕННЫЕ ЗАПРОСЫ Поскольку сайт и БД будут легко загружены, некоторые небольшие запросы, вероятно, будут наименее быстрые и простые для кодирования. Выпустил бы несколько SQL-запросов, а затем объединил бы результирующие объекты в PHP для каждого поиска.

REDUNDANT SEARCH TABLE Я рассматривал возможность записи строки в другую таблицу как индекс ручной работы всякий раз, когда проект редактируется - это приведет к тому, что текстовые значения из связанных полей для тегов, страны, агентства и т. Д. Объединяют их в string и вставьте его в таблицу поиска с идентификатором projectID; в каждой таблице проекта будет одна строка в таблице проекта, представляющая собой денормализованное представление ключевых данных, которые мы можем искать.

Я немного изучил возможности MySQL, но нервничаю из-за отсутствия индексации на них; по крайней мере, избыточный поиск таблицы могут быть тщательно индексируются

Technologies в руки - PHP 5.1.6 и MySQL 5.0.22 работает на RHEL5

Любые мысли, советы или военные истории приветствовать

Спасибо за ваше время

Ян

ответ

0

Я бы определенно посмотреть в функциональности FULLTEXT в MySQL для этого. У меня уже есть answered a question относительно разных подходов поиска, и это решение в основном того, что вам потребуется.

В принципе, в примере FULLTEXT, описанном в этом ответе, вы можете просто создать свою временную таблицу с помощью SELECT, который объявит все поля всех таблиц, которые вы хотите искать (+ их индексный столбец), и объявите свой FULLTEXT индекс в этих полях. Затем просто запросите временную таблицу ...

+0

Hi Yanick, спасибо за это. Какая польза от заполнения временной таблицы каждый раз, что потребует от меня выполнения всех дорогостоящих объединений, которые я пытаюсь избежать, каждый раз, когда выполняется запрос? Почему бы не сохранить отдельную таблицу MyISAM, если бы я хотел использовать функцию FULLTEXT в MyISAM? Спасибо, Ian – Polsonby

+0

@Flubba, заявления JOIN не так дороги, по крайней мере, менее дорогостоящие, чем из нескольких таблиц ... В любом случае, да, вы могли бы поддерживать отдельную таблицу MyISAM с помощью триггера AFTER INSERT/UPDATE/DELETE или вы может использовать сторонний поиск и запускать индексатор после отсроченного периода времени. В любом случае поддержание отдельной таблицы с включенным FULLTEXT не должно выполняться самим проектом, поэтому у вас нет жесткой связи с тем, как выполняется поиск, если вам когда-либо понадобится изменить технологию ... –

+0

интересные мысли, приветствия. .. – Polsonby

0

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

Использование SOLR, например, предоставит вам множество дополнительных и расширенных функций, которые вы можете легко использовать в своем веб-приложении. Например ограненные поиск, предложения орфографические, находя синонимы, функциональность, чтобы найти похожие слова (опечаток) не только точных совпадений и многое другое: features of SOLR

Там также SOLR код клиента для PHP: http://code.google.com/p/solr-php-client/

Кроме ГУМЗ там есть много других поисковых продуктов для достижения такого рода функциональности поиска, как бесплатных, так и коммерческих.

Невозможно самостоятельно создавать такие функции, но с использованием зрелого продукта вы получаете проверенный продукт и множество функций, которые улучшают пользовательский интерфейс, который очень сложно построить.

Смежные вопросы