Консультация по проектированию DB

Question

Я ищу советы по дизайну, над которым я работаю. Это так:

У меня есть база данных с столом для собраний и пользовательской таблицей. На каждом собрании есть организатор, который соответствует идентификатору пользователя в пригодном для использования. Верри просто в этот момент.

Теперь через facebook api я получаю список друзей от каждого человека. Я хочу искать свою базу данных для встреч, организованных моими друзьями. Первое, о чем я думал, это просто простой IN («список друзей») в запросе, но я могу представить, что это убивает производительность.

Идея теперь состоит в том, чтобы создать дополнительную таблицу, содержащую идентификатор пользователя и идентификатор друга, и вставить его в запрос.

Есть ли у кого-нибудь советы о том, что лучше всего работает. Другие решения, конечно, больше, чем прием;)

ТНХ

N

PS. MySQL DB

Answer 1

IN не является фундаментальной проблемой здесь. Но это может быть практической проблемой, если данный оптимизатор СУБД не очень хорош и не может создать оптимальный план запроса. Но в этом случае вы обычно можете переписать свой запрос для использования другого синтаксиса (например, JOIN), который выполняет то же самое, но позволяет оптимизатору создавать лучший план.

MySQL был известен тем, что не оптимизировал INs, поэтому люди, как правило, использовали JOIN по умолчанию. Другие СУБД обычно не имеют таких ограничений. Лучше всего проверить производительность самостоятельно, on representative amounts of data, чтобы узнать, есть ли у вас проблема или нет.

Кстати, вам все равно нужна таблица соединений между собраниями и пользователями - в чем цель встречи, если в конце концов не может быть нескольких участников? И если организатор также следует рассматривать в качестве участника, вы можете сделать что-то вроде этого: