руководство по предварительно вычисленным атрибутам SQL

Question

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

• byte_count и packet_count объекта TcpConnection вычисляются из одни и те же атрибуты двух составляющих его TcpStream объектов, которые в свою очередь являются вычисляется из составляющих их TcpPacket объектов.

• Объект Invoices может иметь total, который в основном является SUM () его составляющие InvoiceLineItems 'цены, с небольшим фрахтом, скидкой и налогом Логика добавлена.

Когда речь идет о миллионах пакетов или миллионах выставленных счетов-фактур (я хочу!), Вычисление по требованию этих производных атрибутов - либо в VIEW, либо чаще в логике представления, такой как отчеты или веб-интерфейсы, - часто недопустимо медленно.

Как вы решаете, до того, как проблемы с производительностью заставят вас подняться, следует ли "продвигать" производные атрибуты в предварительно вычисленные поля?

Answer 1

Лично я не буду денормализовать, пока компромиссы производительности не вынудят мою руку (потому что обратная сторона денормализации слишком радикальна, ИМХО), но вы также можете рассмотреть:

1. Удобство : например, если два разных клиентских приложения хотят вычислить одни и те же производные атрибуты, им обоим нужно кодировать запросы для их вычисления. Денормализация предлагает обоим клиентским приложениям производный атрибут более простым способом.
2. Стабильность во времени : например, если формула для вычисления производного атрибута является изменяемой, денормализация позволяет захватывать и сохранять производное значение в определенный момент времени, поэтому будущие вычисления никогда не получат его неправильным
3. Упрощенные запросы : добавление сложности к структуре БД может означать, что ваш запрос Select будет проще на стороне клиента.
4. Производительность : Выбрать запросы к денормализованным данным можно быстрее.

Ссылка: Программист базы данных: аргумент в пользу денормализации . Обязательно прочитайте также его статью о Сохранение правильных денормализованных значений - его рекомендация - использовать триггеры. Это приносит домой тот вид компромисса, который требует денормализация.

Answer 2

По сути, вы этого не делаете. Вы оставили проблемы с производительностью силой вашей руки.

Это лучший ответ, потому что в 99% случаев вам следует не проводить предварительную оптимизацию, как это, лучше просто рассчитать ее на лету.

Однако разработчики клиентских приложений довольно часто приходят на сервер с ошибочными предубеждениями, такими как " вычисление по требованию ... производных атрибутов ... - * часто недопустимо медленно", и это просто НЕ правда. Правильная формулировка здесь будет такой: « - это редко недопустимо медленно ».

Таким образом, если вы не являетесь экспертом в этом (разработчик БД и т. Д.), Вам не следует заниматься преждевременной оптимизацией. Подождите, пока не будет исправлено очевидное , то затем посмотрите на предварительную агрегацию.

Answer 3

То, насколько актуальными должны быть данные, определяет, как вы на самом деле их реализуете.

Я приму 2 простых состояния: текущий или не текущий.

• Текущий: индексированные представления, триггеры, хранимые процедуры для ведения сводных таблиц и т. Д.
• Не актуально: снимки службы отчетов, доставка / репликация журналов, хранилище данных и т. Д.

Тем не менее, я буду разрабатывать против того же количества данных, что и в prod, поэтому я уверен в времени отклика. Вы редко удивляетесь производительности своего кода ...