@konchober

Sphinx сопоставление индекса найденного значения одного MVA поля с другим?

Внимание! Задача весьма ненормальная и я знаю, что это не целевое предназначение Сфинкса.

Упрощённая структура таблички: id int, default_price int, prices mva, regions mva.
Помимо этих полей содержится ещё десяток текстовых полей.

Пример записи:
id = 5464356; / артикул товара
default_price = 2250; / цена на товар в большинстве регионов
prices = 2500, 1800, 2500, 3250, 1800; / варьирование цены в регионах (акции, распродажи, ликвидации)
regions = 1, 2, 24, 58, 66 / id регионов с нестандартной ценой
Читается так: в регионе №1 цена на товар 2500, во 2 = 1800, в 24 = 2500, в 58 = 3250 и в 66 = 1800.
Во всех остальных регионах цена 2250.

Цель: отсортировать список товаров по цене с учётом цены конкретного региона.
В каждом регионе цена может сильно варьироваться.

Что есть сейчас: SELECT * FROM barahlo ORDER BY default_price;
Чего сейчас нет: получить одно значение из prices mva, индекс которого соответствует индексу найденному в поле regions

Как я это вижу решение на псевдо-SQL:
SELECT *, IF(regions IN (58), VALUEFROMMVA(prices, regions IN (58)), default_price) sort_price FROM barahlo
ORDER BY sort_price;

Альтернативное решение: так как регионов более 100, а товаров ещё десятки тысяч, то индекс цены отдельным полем для каждого региона + 10 текстовых полей будет выглядеть слишком ужасающе.
Но похоже, что это единственный бескостыльный вариант.
  • Вопрос задан
  • 3134 просмотра
Решения вопроса 1
@konchober Автор вопроса
Вопрос решён без костылей и создания громадного индекса =)
В качестве «примари кея» взял связку id + price, а в regions список регионов с этой ценой.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 1
@klirichek
Да, тут "в лоб" задача вообще не решаемая.
у MVA НЕТ никаких индексов. Это аналог структуры Set, а не Vector. Внутри он для удобства хранится в отсортированном по возрастанию виде. Соответственно, ровно в момент когда вы поместите туда prices - дубли уберутся, сами цены отсортируются - и вся предполагаемая схема "развалится".
Так что ваш вариант с включением цены в "primary key" - вполне хорош.
Ещё (как вариация того же самого) можно положить цену в отдельное ft-поле (тогда в поиске получится что-то вроде '@title iPhone 5S @price 2500'. Или (ещё вариант) не в поле а в спец.токен ("price2500").
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы