Выборка статистических данных бд
Вопрос может не совсем технический, а относящийся к проектированию. В базе данных есть таблица users и много таблиц статистики -например ranks, view_count, likes и т.д., где примерная схема структур -id, user_id(кто смотрел или ставил лайк) user_id2 (кому поставили лайк или кого смотрели). Вопрос, как грамотно спроектировать таблицы , если юзеров и записей в таблице статистики очень много будет. Понятное дело , что путем count(), или sum() можно вытягивать по id юзера, но эти данные должны отображаться в листе превьюшек юзеров , как в соцсети (визульно фото, чуть ниже -рейтинг, кол-во просмотров, кол-лайков).Правильно ли так делать, что в общей таблице того же rank искать по id юзера и делать громозкие count() и sum() ?
Ответы (1 шт):
С ходу вижу 3 принципиальных подхода:
- Классическая нормализованная база, подсчет sum/count на лету.
Плюсы: быстрая вставка/изменение/удаление. Всегда актуальные данные
Минусы: относительно медленное чтение - Денормализация (вынос подсчитанных sum/count в какую-либо таблицу) с пересчетом на триггерах
Плюсы: Быстрое чтение, всегда актуальные данные
Минусы: Медленная вставка/изменение/удаление - Денормализация с отложенным пересчетом
Плюсы: Быстрое чтение, быстрая вставка/изменение/удаление
Минусы: Данные не всегда актуальны
Выбор зависит от количества данных, количество одновременно подключенных пользователей (если и то и другое небольшое, то "медленно" будет измеряться долями секунды), и требованиям к актуальности данных.
Например, для соц-сетей с сотнями миллионов пользователей и миллиардами записей нет ничего страшного, если пользователь увидит лайк не сразу, а через час-другой.