Сложность выбора одного метода перед другим для получения данных из Mysql

Question

Я работаю над проектом, основанным на PHP, Mysql, Apache.

У меня есть модуль, называемый уведомлением, который аналогичен уведомлению, доступному в FACEBOOK, для этого у меня есть 3 способа

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

2-й способ

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

3-й способ

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

Я считаю, что все три способав какой-то момент проблематичны.

Теперь кто-нибудь может предложить какую-нибудь лучшую идею или какой из них лучше?

Я обеспокоено производительности сайта, так как он будет иметь массовые записи

Спасибо

Answer 1

Поддержка триггеров в MySQL в лучшем случае скудна, поэтому я бы не стал продвигаться в этом направлении, хотя это мог бы быть хороший способ сделать это.

Самый легкий способ сделать это будет следующим: для каждого входа в систему / выхода из системы вставляйте / удаляйте пользователя из «онлайн-пользователей» .id, а затем создайте внешний интерфейс (который в любом случае должен делать дерьмо) время от времени спрашивайте, какие из идентификаторов, которых он знает, находятся в таблице.

Объединения, помимо того, что они не очень умны в mysql, будут большими на больших таблицах даже с индексами.

Триггеры, точно так же, и что бы вы попросили сделать триггер? нажать на все, что этот человек вошел в систему? подтолкнуть к интересующимся? это означает еще одно объединение, то есть снижение производительности.

Таблица уведомлений? абсолютно огромный и медленный без причины (то есть 100 вставок вместо одной, где запрос .. мэ).

Answer 2

Это было немного сложнее, чем я сначала подумал:)

Как поведение приложения / пользователя?Когда мы должны сделать большую часть работы?При вставке данных или при извлечении данных.

Мне нужно будет сделать предположения о том, какие операции будут наиболее распространенными.Я бы предположил, что выборка данных будет немного более распространенной, так как многие пользователи увидят уведомление о непрочитанных сообщениях, но только одну «вставку» нового сообщения?

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

Но я думаю, что модель должна быть установлена ​​перед любой оптимизацией, это более важно.Оптимизациями позже можно будет управлять, используя денормализацию , планирование и т. Д. Я бы не стал трогать триггеры, они немного прикольные ИМХО.

Я также сделаю другой подход.

Пользователь пишет новое сообщение :

• Вставить сообщение

• Обновить категорию user_category (имеет много) как обновленную в то время

  ОБНОВЛЕНИЕ user_category SET last_changed = 'NOW ()' где category_id =?;

Как найти непрочитанные сообщения пользователей :

• Выберите категории, которые были обновлены с тех пор, как пользователь в последний раз просматривал их (грязные?).
• Выберите все сообщения из тех категорий, которых нет в 'user_message_noticed' (см. Ниже).

Пользователь прочитал сообщение

• Вставьте строку в схему * user_message_noticed *, которая связывает сообщения и пользователей.Идентификатор категории есть, поэтому мы можем быстрее выполнить выше без дополнительного объединения.

Для всех сообщений, прочитанных из этой категории - Обновление * user_category ™ (имеет много много) сдата, когда пользователь прочитал все сообщения.

Но иногда, вы не можете уйти от выполнения реальной работы.