Я работаю над веб-приложением и хотел бы иметь возможность отображать некоторую вычисленную статистику о различных объектах для пользователя.Вот несколько хороших примеров: страница «Самые популярные вопросы» на этом сайте - ТАКИЕ - на которой перечислены «Голоса», «Ответы» и «Просмотры» или «Комментарий» и «Мне нравится» для списка сообщений в Facebook.Новостная лента.Фактически вычисленные значения, подобные этим, используются во всем Интернете, и я не уверен, что это лучший способ их реализовать.
Я опишу более подробно общее представление о проблеме.У меня есть одна родительская таблица в моей базе данных (вы можете представить ее в виде записи в блоге).Эта таблица имеет отношение «один ко многим» с 5 другими таблицами (визуализируйте ее в виде комментариев, лайков и т. Д.).Мне нужно отобразить список из ~ 20 объектов родительской таблицы со счетчиками для каждого связанного дочернего объекта (визуализируйте его как список сообщений в блоге, каждый из которых отображает общее количество комментариев и общее количество лайков).Я могу придумать несколько способов решения этой проблемы, но я не уверен, какой из них будет БЫСТРЫМ и наиболее ТОЧНЫМ.
Вот несколько вариантов, которые я предложил ...
A) Триггер SQL - создайте триггер для увеличения и уменьшения столбца вычисленного числа в родительской таблице, поскольку дочерние таблицы выполняют вставки и удаления.Не уверен насчет компромиссов производительности, запускающих триггер каждый раз, когда создается или удаляется маленький дочерний объект.Я также не уверен в потенциальных проблемах параллелизма (хотя в моей нынешней архитектуре каждая строка в БД может быть добавлена или удалена только создателем строки).
B) Представление SQL - просто более простой способ сделать запрос идают точные результаты, но меня беспокоит влияние на производительность для этого типа представления.
C) Индексированное представление SQL - индексированное представление будет точным и потенциально более быстрым, но поскольку каждая дочерняя таблица имеет строки, которые могут бытьПри добавлении или удалении представление будет постоянно пересчитываться.
D) Кэшированные изменения - своего рода промежуточное решение процесса, которое будет кэшировать изменения в дочерних таблицах, вычислять чистые изменения в счетчиках и сбрасывать ихв БД на основе некоторого параметра.Это потенциально может быть связано с процессом, который периодически проверяет точность.
E) Что-то удивительное, о чем я еще не думал :) Как SO отслеживает слишком много статистики ??
- Использование SQL Seerver2008R2
** Пожалуйста, имейте в виду, что я создаю что-то нестандартное, и это не блог / FB / SO, я просто использую их как примерПодобная проблема, поэтому предложение просто использовать эти сайты бесполезно;) Я хотел бы услышать, как это достигается в живых веб-приложениях, которые обрабатывают приличный объем запросов.
СПАСИБО Заранее