Рефераты | Рефераты по информатике, программированию | MSSQL 2005 (Yukon) – работа с очередями и асинхронная обработка данных | страница реферата 6 | Большая Энциклопедия Рефератов от А до Я
Большая Энциклопедия Рефератов от А до Я
  • Рефераты, курсовые, шпаргалки, сочинения, изложения
  • Дипломы, диссертации, решебники, рассказы, тезисы
  • Конспекты, отчеты, доклады, контрольные работы


    • Рефераты | Рефераты по информатике, программированию | MSSQL 2005 (Yukon) – работа с очередями и асинхронная обработка данных


    Рефераты | Рефераты по информатике, программированию | MSSQL 2005 (Yukon) – работа с очередями и асинхронная обработка данных

    MSSQL 2005 (Yukon) – работа с очередями и асинхронная обработка данных




    Категория реферата: Рефераты по информатике, программированию
    Теги реферата: реферат биография, скачать на телефон шпаргалки
    Добавил(а) на сайт: Kozin.



    Предыдущая страница реферата | 1  2  3  4  5  6  7  8  9  10  11 |



    Начнем с DML, идея которых, в общем-то, должна быть очевидна. Допустим, у нас есть очень большая таблица (Very_Big_Table), для отчетов по которой надо периодически считать некие агрегатные значения. Поскольку таблица очень большая, то агрегаты считаются очень долго. Отчет не всегда должен быть актуальным, но всегда – согласованным, и строиться должен максимально быстро. Это значит, что в идеале агрегаты должны быть посчитаны заранее. Делать пересчет данных в обычном триггере накладно для операций обновления, так как расчет агрегатов происходит долго, как уже было упомянуто. И тут на помощь приходит Service Broker. В обычном триггере на изменение Very_Big_Table создается диалог (строго говоря, мало что мешает создать диалог заранее, разве что проблемы с запоминанием метки при развертывании) и отправляется сообщение, о том что таблица изменилась. Это занимает минимум времени, а изменяющий процесс идет дальше заниматься своими делами. Получатель же начинает не торопясь пересчитывать эти занудные агрегаты, чтобы к моменту, когда понадобится отчет, все уже было готово.

    Вот как это может выглядеть. Сначала создадим необходимые тестовые таблички:

    CREATE TABLE Very_Big_Table(ID int IDENTITY, Data bigint, [Time] DateTime)

    GO

    -- заполним таблицу данными

    --

    INSERT INTO Very_Big_Table(Data, [Time])

    SELECT object_id, create_date FROM sys.objects

    GO

    -- табличка для вычисленного агрегата

    --

    CREATE TABLE Big_Aggregate(Agg bigint, [Time] DateTime)

    GO

    -- Ну и проинициализируем ее

    --

    INSERT INTO Big_Aggregate(Agg, [Time])

    SELECT Sum(Data), GetDate() FROM Very_Big_Table

    Теперь триггер на изменение очень большой таблички. Здесь мы сильно мудрствовать не будем, воспользуемся уже готовыми метаданными из предыдущего примера:

    CREATE TRIGGER AsyncAggregate ON Very_Big_Table

     FOR INSERT, UPDATE, DELETE

    AS

     DECLARE @convHandler uniqueidentifier

     BEGIN DIALOG  @convHandler

      FROM SERVICE  [SourceService]

      TO SERVICE   'TargetService'


    Рекомендуем скачать другие рефераты по теме: рефераты на казахском языке, реферат на тему время.



    Предыдущая страница реферата | 1  2  3  4  5  6  7  8  9  10  11 |




    Поделитесь этой записью или добавьте в закладки

       

    Категории:



    Разделы сайта




    •