Оптимальный запрос mysql
1. Известно, что в таблице более 100 млн. записей.
2. Известно, что пользователь при добавлении своего предложения товара вносит такие данные:
Вид товара (через запятую. например: автомобиль, легковой автомобиль, машина)
Бренд (через запятую. например: ВАЗ, LADA)
Модель (через запятую. Например: 2101, Копейка)
Цена (цифры)
Валюта (а базе хранится таблица валют и курсы валют относительно гривны)
3. Известно, что сортировка базы производится по репутации пользователя (есть таблица отзывов о пользователях, в которой хранятся позитивные и отрицательные отзывы).
4. Известно, что пользователь в поиске указал:
Цена: от 4000 до 5000 долларов США
Строка поиска: ВАЗ 2101
У кого есть какие соображения?
Интересно где вы тут увидели вводные данные? Тут что указана структура таблиц и индексы? Или вы телепат?
Вот что пугает.
Вместо попытки разработки слышится странный вопль «А не могли бы вы мне сочинить? А то мне зарплаты не выдадуть!»
И ведь ТЗ вроде ясное, но вот что-то товарищу мешает, и он ломится задать всех ни к чему не обязывающий вопрос: «У кого есть какие соображения?»
Тут или ответьте, пожалуйте, или просто учитесь как вопросы правильно задавать. Ведь такой вопрос подразумевает «я-то знаю, а вам слабО?»
Наивный. Не указаны критерии "оптимальности". Что есть оптимальность? Малое потребление памяти? Может быстрое выполнение запроса? Но на сколько быстро, секунда? минута? полчаса?
По-этому всё что есть - это уникальные айдишники... Так что нужно вести рядом отдельную небольшую табличку id-шников + приоритеты и потом уже вынимать... join'ами... Или другими алгоритмами...
Неправильно известно. Индекс с уникальностью ни как не связан.
join - не алгоритм.
По-этому всё что есть - это уникальные айдишники... Так что нужно вести рядом отдельную небольшую табличку id-шников + приоритеты и потом уже вынимать... join'ами... Или другими алгоритмами...
Да господь с тобой! Перечитай теорию реляционных БД. Индексировать можно кудой хочешь, в частности по автоинкременту, коий не может быть unique, но таковым является. Это наиболее явный парадокс всех БД, но он имеет место быть.
В данном случае мы видим не то абсолютно неправильно поставленное задание, не то написано оно абсолютно неадекватно, что, вобщем-то одно и то же.
Всё равно, имхо, с таким объёмом базы без таблиц сопряжения не обойтись...
Тогда надо начать с постановки задачи. Я бы предложил поставить ее так:
Обязательное условие - получение правильного ответа
Дополнительное условие - быстрый результат поиска
Причем обязательное условие реализуется не так уж и просто.
Если это база данных по автомобилям, то можно ввести кучу полей с характеристиками и тогда запрос типа ВАЗ 2101 можно превратить в запрос по двум полям. Но если это магазин более широкого профиля, тогда сделать поиск по тексту уже сложнее... Один пользователь напишет "vaz2101" другой "21-01 ВАЗ" и т.д.
В таких случаях для быстрого поиска можно вводить отдельную таблицу индексации и писать прогу, которая будет разбирать текстовые поля на части и формировать по ним индекс...
типа таблицы
конечный_автомобиль (id, cost, ...),
типы_автомобилей (typeId, name)
бренды (brandId, name)
модели (modelId, name)
пользователи (userId, name, surname, ... rating)
и таблицы связей типа
автомобиль_тип (id, typeId)
автомобиль_бренд (id, brandId)
автомобиль_модель (id, modelId)
автомобиль_юзер (id, userId)
а потом уже можно написать хоть джойнами, хоть вложенными, хоть последовательными
А кто-то напишет "копейка". А кто-то копье. А кому то зубило нужно. Только ни какого отношения к структуре БД это не имеет. Не нужно смешивать мух с котлетами.
Есть некая общность данных, в данном случае отношение многие-ко-многим в виде объект-свойство. Эта часть имеет отношение к проектированию структуру БД. К примеру, хранить каждое свойство объекта в поле таблицы (вариант любимый drupal-ом), тогда сколько свойств у объекта столько и полей в таблице. Количество таблиц равно количеству объектов. А можно хранить объекты отдельно, свойства отдельно и связывать их через третью таблицу join-ми. А можно свойства вообще сериализовать и хранить в одном поле. Или вообще уйти от реляционной схемы и использовать документо ориентированные решения. Вариантов масса.
Поисковые запрос это поисковый запрос. В нем могут быть ошибки, в нем могут быть жаргонизмы, профессионализмы, сленг. Ни какого отношения к структуру БД это не имеет. Если используются запросы в свободной форме, то в системе нужен анализатор поискового запроса. Но это другой уровень системы, это не уровень структуры БД.
Когда человек понимает, что это два разных уровня приложения, то поставленная задача решается очень легко. Если не получается написать анализатор самому, можно использовать готовые, к примеру тот же Яндекс.Сервер. В конечно итоге не подойдет готовое решение, можно убрать свободный поиск, а пользователю выдавать готовый список возможных значение из которого он выбирает нужный (автомобиль - марка - модель ....).