Представление SQL или таблица
У меня есть таблица данных, которые получают обновление один раз в неделю. У меня затем есть запрос, которые обрабатывают эти данные, и по существу возвращает список кодов и сумму часов, заказанных к тем кодам. Этот запрос является обоснованно сложным и занимает приблизительно 5 секунд для выполнения.
Эти данные должны использоваться большим другим запросом в DB, таким образом, я хочу поместить его где-нибудь, что к этому может получить доступ легко другой запрос. Выполнение этого в поле зрения походило на хорошую идею, но это означает, что каждый раз это представление называют, это повторно выполнит этот запрос, занимая 5 секунд, если будет много вызовов к этому сразу затем его попытка заставить приложение замедляться.
Таким образом, я думал, будет это быть лучше создать это представление как таблицу, когда данные будут импортированы в понедельник, поскольку это будет единственным временем, это изменяется. Действительно ли это - лучшая Идея, или я смотрю на это неправильный путь?
7 ответов
Я имею дело с теми же проблемами с большинством моих проектов.
У нас обилие данных, которые необходимо реорганизировать для разных целей. Мы также получаем пользу от корпоративной культуры, которая используется для пакетных заданий и ночных процессов, поэтому пользователи хорошо образованы о природе данных. Первое, что большинство пользователей экспортируют данные в Excel, поэтому это не проблема.
Использование дополнительных таблиц - это разумный способ пойти сюда.
Лично я префикс эти таблицы с подчеркиванием.
_LargeUsefulData
Это позволяет мне легко определять удобные таблицы от объектов, которые играют активную роль в обычных операциях системы.
Сотрудник указывал на «материализованные взгляды».
http://www.pgcon.org/2008/schedule/attalhments/64_bsdcan2008-materializedviews-spape.pdf
В основном вы копируете данные с вида в таблицу и используете эту таблицу в качестве представления. Точка в этой презентации (ссылка) состоит в том, что вы можете работать с триггерами и функциями для обновления только некоторых порций этой таблицы.
Очень полезно, я реализовал такой материализованный вид на SQL Server.
звучит как разумный способ пойти об этом.
Поскольку запрос дороги, поместив результаты в таблицу «Отчет», которая должна использоваться другими приложениями, звучит как хороший компромисс.
До тех пор, пока пользователи этих данных довольны его изменением, когда вы описываете, ваш подход в порядке.
Если ваша структура представления позволяет индексировать его, вы можете создать индексированное представление (которое на самом деле является просто копией данных, обновляемых при обновлении нижележащих таблиц).
Однако не каждый запрос позволяет индексировать представление над ним.
Если ваши данные не должны быть актуальными каждую секунду, то создание таблицы - OK.
Вы все еще "просматриваете" ваши строки, будь то в таблице или в представлении строк таблицы.
Сначала я попытаюсь оптимизировать ваш запрос (ударить по индексам, может быть, добавить/обновить/изменить индексы) и прогоню его через профайлер. Профилировщики дают прекрасное представление... о плане принятия решений в ваших базах данных.
Я сталкивался со схожими проблемами в моей производственной поддержке, когда мне нужно было работать с большим хранилищем данных. По сути, я создал таблицы, используя сценарий оболочки. Сценарий оболочки работает следующим образом:
- Если временная таблица существует, бросьте это.
- Выполните запрос, создав таблицу. например, создать таблицу x как (выберите ....)
- Использовать временную таблицу и творить как временный таблицы/исключения.
- Бросьте временную таблицу, если не хотите. больше не нужна или оставишь себе, если ты... не думай, что он съест твой диск. пространство.
Все это можно сделать с помощью простого скрипта оболочки. Я обнаружил, что он очень полезен и даже сейчас работает эффективно.
Да, это первый шаг в направлении хранилища данных :) Конечно, вы должны убедиться, что ваша новая таблица всегда построена после каждого еженедельного обновления.