Представления VS Таблицы Для "Facebook", как канал

Question

В настоящее время я разрабатываю ленту для панели управления, которая работает аналогично каналу Facebook. Фид будет содержать следующее:

• Уведомление пользователя о новых пользователях
• Показать рефералов, отправленных пользователям, полученных рефералов
• Новости от администратора
• До предстоящих событий.

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

Итак, я рассмотрел свое решение с моим менеджером, и он сказал, что, возможно, было бы лучше использовать представление, потому что SELECT потребляет намного меньше ресурсов, чем обычное удаление и вставка. Я согласен с ним, потому что в начале каждой загрузки страницы я должен выполнять уборку дома на столе, удалять неиспользуемые записи, удалять элементы, которые больше не действительны, и заполнять обновленными данными. Теперь, если они продолжат обновлять, не будет никакой работы, поэтому снижение производительности не является плохим, но если 1000 пользователей одновременно обращаются к сайту, может быть огромный спад производительности, если эта одна таблица заполняется для все эти пользователи.

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

Вот что нужно сделать для уведомления:

1. Показать актуальную информацию из нескольких таблиц
2. эти элементы должны быть смешаны и упорядочены по дате, введенной системой
3. Некоторые из них будут липкими, а некоторые не будут зависеть от того, что решит администратор (пока они будут статически установлены)
4. Возможность удалять предметы из списка
5. Каждый пользователь будет иметь свою собственную область для отображения своих предметов.
6. элементов, которые всегда будут отображаться для новых пользователей. Например, если есть приветственное сообщение, которое должно отображаться при первом входе пользователя в систему
7. если количество уведомлений превышает 100, удалите все уведомления после 100 и никогда не показывайте их, даже если количество уведомлений меньше 100

Вот мои две таблицы, которые помогают мне выполнить эту задачу:

уведомлений
- id
- user_id (если это значение равно NULL, этот элемент доступен для просмотра всем пользователям)
- table_pk (основной идентификатор таблицы, на которую ссылается
- таблица (таблица, на которую ссылается эта строка)
- липкий (это предмет липкий)
- дата добавлена ​​(дата добавлена)

notifications_removed
- id
- уведомление_
- user_id

Прямо сейчас у меня есть функция обновления, которая заполняет эту таблицу, но мой менеджер думал, что мы избавимся от таблицы уведомлений и превратим ее в представление. Будет ли польза от этого? Как уже упоминалось, эти элементы будут обновляться каждый раз, так что снижение производительности заключается в том, что мой способ должен будет выполнить очистку таблицы таблицы уведомлений, тогда как представление просто выбирает и объединяет вещи вместе. С другой стороны, единственным недостатком, который я вижу в представлении, является то, что я потеряю гибкость и историю уведомлений, что сейчас не так уж и важно.

Answer 1

Нематериализованное представление (MySQL не поддерживает материализованные представления) ничем не отличается от подготовленного оператора SELECT - вы можете запускать два рядом друг с другом, и производительность идентична. Простые предложения (предикаты) WHERE, применяемые к представлению, могут быть вставлены во внутренний запрос, но это означает отсутствие манипулирования данными (IE: функция для столбца, агрегатные функции и т. Д.).

Замена уведомлений на представление суммируемых данных уменьшит ОБНОВЛЕНИЯ таблиц, сделав систему более "в реальном времени". Вам нужны исторические данные под рукой? Вы можете восстановить его из резервных копий (хотя восстановление данных по многим резервным копиям будет грязным), или вы можете добавить флаг к данным, чтобы удаленные данные не были удалены из таблицы - флаг просто контролирует видимость (но это означает хранение большего количества данных).

Ранее

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