Привязка статуса пользователем к товарам

Question

[Аркадий]

Есть к примеру две таблицы в базе

TABLE `produces` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(200) NOT NULL,
PRIMARY KEY (`id`)
и
TABLE `produces_user_status` (
`produce` int(11) unsigned NOT NULL,
`user` int(11) unsigned NOT NULL,
`status` enum('1','2','3','4') NOT NULL,
UNIQUE KEY `key` (`produce`,`user`)

Пользователь может отметить любой товар статусом 1, 2, 3 или 4. Далее уже через sphinx мне нужно достать товары по @user_id и @status.

Есть пока слабый вариант реализации:

Создать MVA атрибуты:

uint status_1 = produce, user ... where status=1
uint status_2 = produce, user ... where status=2
...

Выборка происходит так: SetFilter('status_1', id user)

Но, если очень много пользователей поставит статус, эти данные будут бегать через сеть в ответе…

Как еще можно реализовать подобное?

Answer 1

[Shedar]

Если проблема в том, что эти данные будут бегать по сети в ответе — можно использовать SetSelect, чтобы не получать эти MVA атрибуты.
Если товаров планируется много, то можно подумать о введении спец-слов. Поскольку поиск по атрибутам сфинкс делает фулсканом. Это работает быстро за счет держания атрибутов в памяти, но всё же. Потому для высокоселективных запросов (пользователь не может проставить статусы миллиону товаров чисто физически) можно ввести слова с id юзера и id статуса, или просто id юзера. И создать полнотекстовое поле, куда их заносить. При поиске соответственно фильтровать по этому полю по сформированному спец-слову.

Comments

[Аркадий]

Думал уже не ответят)

По поводу спец-слов, забыл отметить что мне нужно данные держать актуальными, я обновляю статус через метод UpdateAttrs. Со спец словами такого обновления не построить (насколько я знаю?)

[Shedar]

RT индексы позволяют. но у них есть свои ограничения — sphinxsearch.com/docs/current.html#rt-caveats
В плане обновления MVA атрибуты тоже не очень. Обновленные значения не сохраняются, в отличии от простых атрибутов:
«Due to internal technical difficulties, currently it is not possible to store (flush) any updates on indexes where MVA were updated; though this might be implemented in the future. In the meantime, MVA updates are intended to be used as a measure to quickly catchup with latest changes in the database until the next index rebuild; not as a persistent storage mechanism.»

[Аркадий]

Про RT читал, но думаю с обновлением MVA все намного быстрей, а сохранение на диск будет при следующем переиндексировании.