Visão geral do controle de alterações
O SQL Server 2008 introduz o controle de alterações, uma solução leve que provê um mecanismo de controle de alterações eficiente para aplicativos. Em geral, para permitir que os aplicativos consultassem as alterações nos dados de um banco de dados e acessassem as informações relacionadas às alterações, os desenvolvedores de aplicativos precisavam implementar mecanismos personalizados de controle de alterações. A criação desses mecanismos costumava envolver muito trabalho e, com freqüência, o uso de uma combinação de gatilhos, colunas de timestamp, novas tabelas para armazenar as informações de controle e processos personalizados de limpeza.
Tipos distintos de aplicativos têm requisitos diferentes quanto à quantidade de informações que precisam sobre as alterações. Os aplicativos podem usar o controle de alterações para responder às seguintes perguntas sobre as alterações feitas na tabela de um usuário:
Que linhas da tabela de um usuário foram alteradas?
Só é necessário o fato de que uma linha foi alterada, e não quantas vezes ela foi alterada ou os valores das alterações intermediárias.
Os últimos dados podem ser obtidos diretamente da tabela que está sendo controlada.
Uma linha foi alterada?
- O fato de que uma linha foi alterada e as informações sobre a alteração devem estar disponíveis e serem registrados no momento em que a alteração foi feita na mesma transação.
Observação |
---|
Se um aplicativo precisar de informações sobre todas as alterações feitas e os valores intermediários dos dados alterados, talvez seja adequado usar o Change Data Capture, em vez do controle de alterações. Para obter mais informações, consulte Comparando a captura de dados de alterações e o controle de alterações e Captura de dados de alterações. |
Aplicativos de sincronização unidirecional e bidirecional
Os aplicativos que precisam sincronizar dados com uma instância do Mecanismo de Banco de Dados do SQL Server devem ser capazes de consultar alterações. O controle de alterações pode ser usado como uma base para aplicativos de sincronização unidirecional e bidirecional.
Aplicativos de sincronização unidirecional
É possível criar aplicativos de sincronização unidirecional, como um aplicativo cliente ou de cache de camada intermediária, que usem o controle de alterações. Como mostra a ilustração a seguir, um aplicativo em cache exige que os dados sejam armazenados no Mecanismo de Banco de Dados e no cache de outros armazenamentos de dados. O aplicativo deve ser capaz de manter o cache atualizado com as alterações feitas nas tabelas do banco de dados. Não há nenhuma alteração para devolver ao Mecanismo de Banco de Dados.
Aplicativos de sincronização bidirecional
Também é possível criar aplicativos de sincronização bidirecional que usem o controle de alterações. Neste cenário, os dados em uma instância do Mecanismo de Banco de Dados são sincronizados com um ou mais armazenamentos de dados. Os dados nesses armazenamentos podem ser atualizados, e as alterações devem ser sincronizadas novamente com o Mecanismo de Banco de Dados.
Um bom exemplo de aplicativo de sincronização bidirecional é um aplicativo ocasionalmente conectado. Nesse tipo de aplicativo, um aplicativo cliente consulta e atualiza um armazenamento local. Quando houver uma conexão disponível entre um cliente e um servidor, o aplicativo será sincronizado com um servidor, e os fluxos de dados alterados ocorrerão nas duas direções.
Os aplicativos de sincronização bidirecional devem ser capazes de detectar conflitos. Ocorrerá um conflito se os mesmos dados forem alterados em ambos os armazenamentos de dados em algum momento entre sincronizações. Com a capacidade de detectar conflitos, um aplicativo pode certificar-se de que as alterações não sejam perdidas.
Como o controle de alterações funciona
Para configurar o controle de alterações, você pode usar instruções DDL ou SQL Server Management Studio. Para obter mais informações, consulte Configurando e gerenciando o controle de alterações. Para controlar alterações, o controle de alterações deve ser habilitado no banco de dados e, então, nas tabelas que você deseja controlar no banco de dados. A definição da tabela não precisa sofrer qualquer alteração, e nenhum gatilho é criado.
Após a configuração do controle de alterações para uma tabela, qualquer instrução DML que afete as linhas da tabela fará com que as informações do controle de alterações de cada linha modificada sejam registradas. Para consultar as linhas que foram alteradas e obter informações sobre as alterações, você pode usar as funções de controle de alterações.
Os valores da coluna de chave primária são as únicas informações da tabela controlada que são registradas com as informações sobre as alterações. Esses valores identificam as linhas que foram alteradas. Para obter os últimos dados sobre essas linhas, um aplicativo pode usar os valores da coluna de chave primária para unir a tabela de origem à tabela controlada.
As informações sobre a alteração feita em cada linha também podem ser obtidas usando o controle de alterações. Por exemplo, o tipo de operação DML que causou a alteração (inserção, atualização ou exclusão) ou as colunas que foram alteradas como parte de uma operação de atualização.