Проектирование базы данных: подсчет количества строк - PullRequest
Новая
       4

Проектирование базы данных: подсчет количества строк

4 голосов
/ 28 июня 2010

Я несколько раз сталкивался со следующей ситуацией, и мне было интересно, что лучшие практики говорят об этой ситуации:

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

Наиболее естественный способ сделать это (IMO) - вставить строку дляКаждое посещение и каждый раз, когда администратор запрашивает итоги, подсчитывают количество строк в соответствующей таблице для этого пользователя.Однако в подобных ситуациях может быть тысячи и тысячи строк на пользователя.Если администраторы часто запрашивают итоги, постоянный запрос количества может создать большую нагрузку на базу данных.Таким образом, похоже, что правильным решением является вставка отдельных строк, но одновременно сохраняйте некоторые сводные данные с промежуточными итогами по мере вставки данных (чтобы избежать повторного вычисления этих итогов).

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

1 Ответ

3 голосов
/ 28 июня 2010

Вот пара практик; тот, который вы выберете, будет зависеть от вашей конкретной ситуации:

  1. Доверяйте своей базе данных Многие механизмы базы данных автоматически кэшируют планы запросов (и результаты) часто используемых запросов. Даже если базовые данные изменились, сам план запроса останется прежним. Соответствующие части индексов будут храниться в основной памяти, что делает повторный запуск данного запроса практически бесплатным. Максимум, что вам может понадобиться в этом случае, - это настроить параметры базы данных.

  2. Денормализация базы данных Хотя форма 3-й нормы ( 3NF ) по-прежнему считается подходящей структурой базы данных, по соображениям производительности может возникнуть необходимость добавить дополнительные таблицы, включающие итоговые значения, которые обычно рассчитываются при необходимости с помощью запроса SELECT ... GROUP BY .... Часто эти другие таблицы обновляются с помощью триггеров, хранимых процедур или фоновых процессов. См. Википедию для получения дополнительной информации о Денормализация .

  3. Хранилище данных С Хранилищем данных цель состоит в том, чтобы передавать копии живых данных во вторичные базы данных (хранилища) для запросов и специальных отчетов. Обычно это делается с помощью фоновых процессов с использованием тех методов репликации, которые поддерживает ваша база данных. Эти хранилища часто индексируются более строго, чем это может понадобиться для вашего базового приложения, с целью поддержки больших запросов с огромным количеством исторических данных.

...