PostgreSQL

Adiando as restrições no PostgreSQL

Deferred Constraints – quando e como usá-las

Freqüentemente nos deparamos com a seguinte situação em aplicações suportadas por SGBDs: em grandes transações envolvendo múltiplas dependências entre as tabelas é difícil processar os dados eficientemente devido às restrições impostas pelas constraints. Um exemplo disso seria a atualização de uma chave primária (PK) referenciada por uma ou várias chaves estrangeiras (FK). As colunas que compõem a chave primária não podem ser atualizadas uma vez que deixariam órfãs as tabelas dependentes e estas também não podem ser atualizadas sem que antes haja uma chave primária a ser referenciada. Tradicionalmente este problema era resolvido de duas maneiras ardilosas: desabilitando-se temporariamente as constraints de chave estrangeira ou excluindo-se os registros originais e recriando-os em seguida com os novos valores. Uma vez que nenhuma destas soluções é particularmente satisfatória, SGBDs como Oracle, a partir de sua versão 8.0, e PostgreSQL, a partir de  sua versão 7.3, introduziram um poderoso mecanismo para tratar essa questão: as restrições adiáveis (“deferred constraints”). Este artigo tratará deste assunto especificamente no PostgreSQL, mas o conceito e inclusive alguns comandos aplicam-se também para outros SGBDs. Ao longo deste artigo estaremos chamando sempre pelo nome “restrição adiável”.

As restrições adiáveis

No comportamento padrão do PostgreSQL, as constraints de uma tabela são verificadas a cada instrução DML de alteração (INSERT, UPDATE ou DELETE). A idéia fundamental das deferred constraints consiste, como o nome diz, em adiar as verificações. Com isso, uma restrição adiável é validada apenas ao final da transação, no evento COMMIT. Apesar de o padrão SQL contemplar restrições adiáveis de qualquer tipo, o PostgreSQL limita-se às restrições de chave estrangeira (“foreign key constraints”). Restrições do tipo CHECK e UNIQUE não são adiáveis neste SGBD.

Ao ser criada, uma restrição de chave estrangeira pode ter uma das três características listadas na Tabela 1. A opção default é NOT DEFERRABLE (não adiável em qualquer hipótese), mas este comportamento pode ser mudado se usada a opção DEFERRABLE (adiável). Sendo adiável, a validação inicialmente pode ocorrer de imediato (INITIALLY IMMEDIATE) ou ao final do processo (INITIALLY DEFERRED).