Если вы используете правильные индексы, нет причин, по которым вы не можете хранить все события в одной таблице, не влияя на производительность.
Если вы правильно обработали свой опрос, чтобы ничего не возвращать, когда нет ничего нового, вы можете минимизировать нагрузку, которую каждый клиент имеет на сервер. Если вы также посмотрите на push-уведомление (гибридный метод с отложенным закрытием соединения), это также поможет вам успешно масштабироваться.
Наконец, совершенно не нужно беспокоиться о хранении переменных в клиенте. Это преждевременная оптимизация. Проблемы с производительностью будут связаны с лавиной подключений к веб-серверу от многих пользователей, а также с таблицами в БД без надлежащих индексов.
Об индексах: индекс является "правильным", когда наиболее распространенный запрос к таблице может быть выполнен с поиском и минимальным числом чтений (например, 1-5). В вашем случае это может быть инкрементный идентификатор или дата (если она имеет достаточную точность). Если вы спроектируете это правильно, операция по поиску самого последнего update_id должна быть однократным чтением. Затем, когда ваш клиент отправляет свой ajax-запрос, чтобы увидеть, есть ли обновленное содержимое, сначала выполните запрос, чтобы определить, меньше ли переданное значение (идентификатор или время), чем текущее значение. Если это так, немедленно ответьте новым контентом с помощью второго запроса. Ваша цель - максимально упростить действие «ping», даже если это связано с немного большими затратами при появлении нового контента.
Использование толчка было бы намного лучше, поэтому, пожалуйста, изучите Comet .
Если вы не знаете, сколько операций чтения происходит с вашими запросами, тогда я призываю вас изучить этот аспект базы данных, чтобы вы могли найти его и правильно оценить.
Обновление : предложение клиентам получить ответ «да, есть новый контент», а затем запросить контент, возможно, не самый лучший. Пожалуйста, смотрите Почему Жиры Пин выигрывают для некоторых очень интересных связанных материалов.