Множественные владельцы

[Активист]

Вообщем, есть связка - товар, группа.

У товара может быть одна основная группа и н-ое колиечество групп владельцев, по группе нужно вытаскивать товары (редко такое вообще бывает в моей практике).

Сделал следующее, таблица продукты имеет следующее столбцы, грубо говоря

`id`, `productTitle`, `groups`, где `groups` есть поле типа tinytext.
В ней хранится примерно следующее: 2,4,6,7

Вытащить товары по группе легко, запрос вида

EXPLAIN select * from `catalogProducts` WHERE 6 IN (`groups`);

Но, не используются индексы. Так как товаров там будет немного, всего порядка трех сотен, то запрос обрабатываться быстро.

Вопрос, можно ли заставить использовать индексы?

Есть конечно вариант с таблицей связкой:
`productId` (primary key), `groupId` (index)
И последующие джойны, но это уже большие расходы, по сравнению с простым селектом, или я ошибаюсь? Кто как решает эту задачу?

 

[Вурдалак]

Вопрос, можно ли заставить использовать индексы?

— нет, естественно.

Тут нужна таблица-связка с полями groupId, productId, уникальный ключ на связке этих полей.

 

[Активист]

Почему естественно? Да, же замечательный тип данных SET. Для SQL довольно тривиальная задача.

Гуру Postrgess, там есть что-нибудь подобное?

 

[Активист]

> на связке этих полей.
Почему именно на связке? Какой запрос для вывода предлагаете использовать?

 

[Вурдалак]

Почему естественно?

— потому что MySQL чудеса не творит. Есть конкретная реализация индексов:
http://dev.mysql.com/doc/refman/5.0/en/mysql-indexes.html:

Most MySQL indexes (PRIMARY KEY, UNIQUE, INDEX, and FULLTEXT) are stored in B-trees

http://en.wikipedia.org/wiki/B-tree

Если попроще, то тут уже как-то приводили пример с телефонной книгой, где есть закладки типа «AA», «AБ», ..., «ЯЯ». Множество этих закладок — индекс.

При твоём запросе MySQL вынуждена парсить все поля `groups`.

замечательный тип данных SET

— http://dev.mysql.com/tech-resources/articles/mysql-set-datatype.html#whynot:

The MySQL SET datatype is not commonly used for a few reasons; ... Fourth, an INDEX on a set datatype is going to refer to the set as a whole and will not be used for searching individual elements (this may or may not be a problem for certain applications)

Почему именно на связке?

— я предположил, что всё-таки группа может иметь только уникальные товары.

Какой запрос для вывода предлагаете использовать?

— тоже пьёшь что ли, как triumvirat?

SELECT `p`.* FROM `groupProducts` AS `gp`
JOIN `catalogProducts` AS `p` ON `gp`.`productId` = `p`.`id`
WHERE `gp`.`groupId` = 42

 

[Активист]

Спасибо. Я по запросу - смутил составной индекс, посмотрю бечмарк по индексам (где как сколько) на реальных результатах, посмотрим что выгоднее

ЗЫ: не пью уже давно, только по конкретным праздникам.

 

[korchasa]

Так как товаров там будет немного, всего порядка трех сотен, то запрос обрабатываться быстро.

Вопрос, можно ли заставить использовать индексы?

Зачем, если и так работает быстро?

 

[Активист]

Что бы не приучаться к плохому. Привычка - при возникновении пробела в понимании - понять и сделать правильно сразу.

MySQL SET datatype кстати, очень не плох для реализации прав и etc, ибо поддерживает хорошо бинарные операции)

 

[korchasa]

SET в данном случае нельзя использовать не только из-за индекса, а еще и из-за того, что для добавления новой категории придется править таблицу. Это вообще странный тип - единственный его плюс по сравнению с int - ограничение множества возможных значений на уровне БД. Что для меня сомнительный плюс, т.к. явно смешивает метаданные и данные.

Не бывает "правильно", бывает "правильно в таком то случае".

MySQL SET datatype кстати, очень не плох для реализации прав и etc, ибо поддерживает хорошо бинарные операции)

Не только SET.

 

[Sad Spirit]

Гуру Postrgess, там есть что-нибудь подобное?

В Postgres'е есть массивы, и вроде бы для поиска элементов в массивах могут использоваться специальные индексы (GIN). С другой стороны, прямо там же, где описываются массивы, предлагается не использовать их для того, чего ты хочешь, а делать таблицу-связку:

Tip: Arrays are not sets; searching for specific array elements can be a sign of database misdesign. Consider using a separate table with a row for each item that would be an array element. This will be easier to search, and is likely to scale better for a large number of elements.

 

[fixxxer]

явно смешивает метаданные и данные

Собственно и ENUM туда же. Но тем не менее бывает удобно.

Искать по сетам не надо, никто же не пытается в здравом уме искать по like '%x%'. Один хрен. Нужен поиск - делай таблицу и связи.

 

[grigori]

никто же не пытается в здравом уме искать по like '%x%'.

it depends
e.g. у меня 5к юзеров в mlm-бизнесе, где надо хранить иерархию рефералов,
я записал их в виде ",135,287,385,"
поиск where referral like "%,135,%" в админке работает, и деревья строить удобней, и вывод списка для каждого 1м запросом
надо - перепишу на связи, но надо ли? вряд-ли

 

[tz-lom]

надо - перепишу на связи, но надо ли? вряд-ли

в принципе это архимедленно,другое дело если это нужно для какого нибудь "хитрого места" которое редко используется,то можно и оставить
но как говорится что вся соль в том что деревья это не так и сложно...

 

[Активист]

grigori
Если не секрет простой селект с нокеш сколько занимает?

 

[grigori]

это было года 4 назад, не помню, но незаметно
не мерял - это надо было только в админке для анализа
а на сайте - только простой вывод подстроки