SQL View или таблица

Question

У меня есть таблица данных, которая обновляется раз в неделю. Затем у меня есть запрос, который обрабатывает эти данные и возвращает список кодов и количество часов, зарезервированных для этих кодов. Этот запрос достаточно сложный и занимает около 5 секунд.

Эти данные должны использоваться многими другими запросами в БД, поэтому я хочу поместить их куда-нибудь, чтобы к ним можно было легко получить доступ другими запросами. Делать это в представлении казалось хорошей идеей, но это означает, что каждый раз, когда вызывается это представление, он перезапускает этот запрос, занимая 5 секунд, если за один раз происходит много вызовов, то это вызовет приложение для замедления.

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

Answer 1

Сотрудник указал мне на «Материализованные взгляды».

http://www.pgcon.org/2008/schedule/attachments/64_BSDCan2008-MaterializedViews-paper.pdf

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

Очень полезно, я реализовал такое материализованное представление в SQL Server.

Answer 2

Я имею дело с теми же проблемами с большинством моих проектов.

У нас имеется большое количество данных, которые необходимо реорганизовать для различных целей. Мы также извлекаем выгоду из корпоративной культуры, которая используется для пакетных заданий и ночных процессов, поэтому пользователи хорошо осведомлены о природе моментальных снимков. Первое, что нужно большинству пользователей, это экспортировать данные в Excel, так что это не проблема.

Использование дополнительных таблиц - разумный путь.

Лично я ставлю эти таблицы с подчеркиванием.

_LargeUsefulData

Это позволяет мне легко идентифицировать таблицы удобства из сущностей, которые играют активную роль в нормальной работе системы.

Answer 3

Звучит как разумный способ сделать это.

Поскольку запрос дорогой, помещение результатов в таблицу «отчета», которая будет использоваться другим приложением, звучит как хороший компромисс.

Пока пользователи этих данных довольны тем, как они меняются, как вы описываете, ваш подход в порядке.

Answer 4

Если ваша структура представления позволяет индексировать ее, вы можете создать индексированное представление (которое на самом деле является просто копией данных, обновляемых при обновлении базовых таблиц).

Однако не каждый запрос позволяет индексировать представление по нему.

Если ваши данные не являются фактическими с точностью до секунды, то создание таблицы будет OK.

Answer 5

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

1. Если временная таблица существует, отбросить это.
2. Запустите запрос, создав таблицу как создать таблицу х как (выберите ....)
3. Используйте временную таблицу и создать как временный столы / первенствует.
4. Бросьте временную таблицу, если вы этого не сделаете нужно больше или держать его, если вы не думай, что он съест твой диск пространство.

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

Answer 6

Да, это первый шаг в направлении хранилища данных :) Конечно, вы должны убедиться, что ваша новая таблица всегда создается после каждого еженедельного обновления.

Answer 7

Вы по-прежнему «просматриваете» свои строки, будь то в таблице или в представлении строк таблицы.

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