Индексирующее поле SET - PullRequest
       9

Индексирующее поле SET

1 голос
/ 15 апреля 2010

У меня есть две сущности А и В. Они связаны многими со многими. Объект A может быть связан с до 100 объектами B. Объект B может быть связан до 10000 объектов. Мне нужен быстрый способ выбрать, например, 30 объектов A, которые связаны с указанными объектами B, отфильтрованы и отсортированы по различным атрибутам.

Вот как я вижу идеальное решение: я помещаю всю информацию, которую я знаю об объектах A, включая их отношения с объектами B, в одну строку (специальная таблица с полем SET), затем добавляю все необходимые индексы. Проблема в том, что вы не можете использовать индекс при запросе по полю SET. Что я должен делать? Я могу заменить базу данных чем-то другим, если это поможет.

ОБНОВЛЕНИЕ: извините. Похоже, я забыл упомянуть одну важную деталь. Мне нужно найти те записи A, которые имеют отношения с записью B с id = 1 и с записью B с id = 2 одновременно. Так что если я использую соединения, у меня будет что-то похожее на:

ВЫБЕРИТЕ a.id, считайте (*) как cnt ИЗ ВНУТРЕННЕГО СОЕДИНЕНИЯ ab on a.id = ab.a_id ГДЕ ab.b_id IN (1,2) GROUP BY a.id ЗАКАЗАТЬ НА NULL с cnt = 2

Что дает мне очень плохую производительность

1 Ответ

1 голос
/ 15 апреля 2010

Почему бы вам просто не сделать это:

SELECT  *
FROM    a
WHERE   a.id IN
        (
        SELECT  ab.a
        FROM    b
        JOIN    ab
        ON      ab.b = b.id
        WHERE   b.id IN (1, 2, 3, 4)
        )

и создайте PRIMARY KEY на ab (b, a)?

Обновление:

Используйте это:

SELECT  *
FROM    a
WHERE   (
        SELECT  COUNT(*)
        FROM    ab
        WHERE   ab.a = a.id
                AND ab.b IN (1, 2, 3, 4)
        ) = 4
ORDER BY
        ...
LIMIT 30

или это:

SELECT  a.*
FROM    (
        SELECT  a
        FROM    ab
        WHERE   ab.b IN (1, 2, 3, 4)
        GROUP BY
                a
        HAVING  COUNT(*) = 4
        ) q
JOIN    a
ON      a.id = q.id
ORDER BY
        ...
LIMIT 30

Вам нужно будет PRIMARY KEY на ab (b, a) (в этом порядке), чтобы это работало быстро.

Какой запрос более эффективен, зависит от вашего распределения данных.

...