2010-04-25 3 views
1

В DB2 поддерживается поддержка материализованной таблицы запросов (MQT). В основном вы пишете запрос и создаете MQT. Но отличие от представления заключается в том, что запрос предварительно выполнен и результирующие данные хранятся в MQT, и есть некоторые опции, когда необходимо обновить/синхронизировать MQT с базовыми таблицами.Материализованная таблица запросов в SQL Server 2005

Я хочу такую ​​же функциональность в SQL Server. Есть ли способ достичь такого же результата?

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

Любые подсказки, ответы, предложения и идеи приветствуются. Спасибо.

ответ

1

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

Простой способ сделать то, что вы хотите, чтобы:

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

Нуждается ли обобщенные данные должны быть подготовлены на (или «по состоянию») в определенное время, например, как 12:01 утра? Если это так, создайте задание агента SQL и настройте его для запуска процедуры в 12:01. Могут ли обобщенные данные быть подготовлены только после предварительной процедуры или двух подготовленных или завершенных данных предыдущего дня? Если это так, добавьте вызов в процедуру суммирования в конце этого процесса.

(Как бы это быть сконфигурировано это в DB2? Как вы определяете, или настроить, когда МКТ обновляется?)

+0

1) Привет, Филипп. Спасибо за Ваш ответ. Я делал то же самое, что и вы предлагали здесь. Я хочу сделать «материализацию», когда есть минимальное количество пользователей (около 3:00 утра). Но я не знал, что это называется SQL Agent (я просто предполагал, что должна быть такая базовая функциональность, которая выполняет SQL в предопределенные интервалы времени). О DB2 2) Честно говоря, я забыл детали, но что-то вроде DEFERED REFRESH и поставлю некоторые опции, чтобы обновить (???) (я понял, что достаточно 8 месяцев, чтобы забыть подробности). –

1

Да, посмотрите на эту статью http://msdn.microsoft.com/en-us/library/cc917715.aspx о «индексированных зрения»

и смотреть также по выбору (С SCHEMABINDING)

+0

Я исследовал этот вопрос, прежде чем отправлять сюда. Это означает, что Indexed View не выполняет предварительный запрос и сохраняет результат и не предоставляет параметры обновления. Для достижения того, что я хочу, я думаю, мне нужно создать индекс для всех столбцов представления. Но даже это не дает мне освежающих вариантов, и данные относятся по запросу. Я прав? Или неправильно понял? –

+0

Хм, когда вы создаете представление, вы должны иметь в виду, какие запросы выполняются с этим. Включение всех возможных столбцов может привести к ухудшению производительности для операций модификации. Возвращаясь к вашему вопросу «Я хочу, чтобы эта таблица обновлялась каждую ночь». - msdn явно обрабатывает его: «SQL Server автоматически поддерживает представления, поэтому любые изменения в базовой таблице, на которой определяется представление, могут инициировать одно или несколько изменений в индексах представления. Таким образом, возникают дополнительные служебные накладные расходы». Так может быть лучшим решением является отдельная таблица для ночной промывки или OLAP-куба? – Dewfy

+0

Разрешает ли OLAP-куб обновлять через некоторый интервал, но не каждый раз данные изменяются? Это швы, что кривая обучения для Data Cube была бы высокой (хотя я знаю, что Data Mining и OLAP). Если SQL-сервер не поддерживает MQT, обходные пути будут автономными таблицами, а триггеры просыпаются каждую ночь и обновляют таблицу. –

2

Это швы, которые индексированные View не предварительно выполнить запрос и магазин его результат и не указывать вариантов.

Но это абсолютно!

«Индексированный просмотр» представляет собой материализацию представления в SQL Server - результирующие данные собираются и сохраняются на диске. Таким образом, запрос предварительно выполнен в этом смысле.

И нет, вам не нужно индексировать на каждое поле - просто факт, что кластерный индекс для представления (на основе подходящего столбца) фактически сохраняет полученные данные на диске. В SQL Server кластеризованный индекс - это данные, действительно.

проверить эту статью в SQL Server 2000 Books Online: Creating an Indexed View

Microsoft ясно пишет:

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

+0

«DB2 предоставляет так называемые« материализованные таблицы запросов »(MQT) с той же целью. Microsoft SQL Server представил в своих индексированных представлениях версии 2000, которые хранят только отдельный индекс из таблицы, но не все данные» - википедия думает в так же, как и я. Если ваш случай является истинным, то когда данные синхронизируются между базовыми таблицами и представлением? –

+0

@Azho KG: Википедия в этом случае не так. ** сгруппированный индекс ** ** IS ** данные! Когда вы добавляете кластерный индекс в представление, вы ** материализуете ** все данные на диск. Доверьтесь мне. Что касается обновлений: они автоматические - вам ничего не нужно делать. Индексированные представления всегда обновляются. –

+0

«Индексированные виды всегда обновляются». - Это проблема. У меня огромные данные, и я не хочу, чтобы индекс обновлялся, я хочу обновить данные, скажем, полночь. Но для любопытства я попытался сделать кластеризованный индекс в представлении, и я не получил никакого повышения эффективности. Как и в нормальном случае (без индексированного представления), он занимает 10 минут. Любые идеи почему? –

0

Что Вы думаете Abaut Replication, Они сказали, что почти каждый бизнес-сценарий рассматривает репликацию для представления данных

+0

Кажется, не рекомендуется использовать репликацию для моего дела. Я ничего не реплицирую, просто хочу получить резюме, которое оценивается в 0,01% от всех данных.Но спасибо за ваши ответы –