Получил веб-приложение в разработке; требование предоставить одно поле поиска, который осуществляет поиск важных полей в главной таблице, плюс других полей, связанные с помощью 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
Любые мысли, советы или военные истории приветствовать
Спасибо за ваше время
Ян
Hi Yanick, спасибо за это. Какая польза от заполнения временной таблицы каждый раз, что потребует от меня выполнения всех дорогостоящих объединений, которые я пытаюсь избежать, каждый раз, когда выполняется запрос? Почему бы не сохранить отдельную таблицу MyISAM, если бы я хотел использовать функцию FULLTEXT в MyISAM? Спасибо, Ian – Polsonby
@Flubba, заявления JOIN не так дороги, по крайней мере, менее дорогостоящие, чем из нескольких таблиц ... В любом случае, да, вы могли бы поддерживать отдельную таблицу MyISAM с помощью триггера AFTER INSERT/UPDATE/DELETE или вы может использовать сторонний поиск и запускать индексатор после отсроченного периода времени. В любом случае поддержание отдельной таблицы с включенным FULLTEXT не должно выполняться самим проектом, поэтому у вас нет жесткой связи с тем, как выполняется поиск, если вам когда-либо понадобится изменить технологию ... –
интересные мысли, приветствия. .. – Polsonby