Colunas Identity Parte-I - Para que servem e como criar

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (2)  (0)

Neste primeiro artigo de uma série, Paulo Ribeiro ensina o que são, para que servem e como criar colunas Identity no SQL Server!

Colunas Identity Parte-I

Para que servem e como criar

por Paulo Ribeiro

Para que servem colunas identity

Colunas com a propriedade identity ativa geram números inteiros auto-incrementáveis. Essa numeração é exclusiva para a tabela em questão, e não será ajustada se ocorrerem deleções.

Colunas identity são ótimas candidatas para PK’s (= Primary Keys). Uma coluna com a propriedade identity ativada irá identificar as linhas da tabela de forma exclusiva e, por não possui vínculo com as regras do negócio, não estará sujeita a alterações. Relacionamentos com colunas identity são fáceis de codificar e requerem menos recursos do engine do SQL Server para serem executados, pois a igualidade do join será representada por apenas uma coluna.

Como ativar e utilizar colunas identity

A propriedade idtentity dever ser ativada no momento da criação da coluna, mas antes vamos discutir duas características importantes de colunas identity: a numeração inicial (=identity_seed) e o incremento (=increment). Vamos supor que a numeração de pedidos na tabela ped_compra será controlada por uma coluna identity. Como a inserção de pedidos é realizada em dois locais diferentes e os pedidos devem migrar para um cadastro centralizado após o fechamento, optaremos por cadastrar pedidos pares no local de cadastro A e ímpares no local-B. Como o sistema de pedidos irá substituir o atual, deverá preservar a numeração. Como a numeração do último pedido foi 546637, iniciaremos com 546638 no local-A (par) e 546639 no local-B (ímpar). Como não pode existir colisão de pedidos, o incremento será igual a 2 nos dois locais.

Para criar a tabela Pedido com a propriedade identity ativa para nro_pedido no local-A:

<!--[if !supportLists]-->·         <!--[endif]-->No Query Analyzer

create table Pedido

(

nro_pedido int not null identitity (546638,2) primary-key clustered

,dt_emissao smalldatetime not null

,vlr_bruto decimal(10,2) not null

,vlr_descto dec(10,2) not null

)

<!--[if !supportLists]-->·         <!--[endif]-->No Enterprise Manager (ver Figura 1)

<!--[if !vml]--><!--[endif]--> PauloRibeiro_Identity_PtI-Fig01.png

Figura 1. Criando uma coluna com a propriedade identity

Para criação da tabela Pedido no local-B, basta alterar o script de Pedidos para contemplar o range impar de pedidos (seed=546639)

Colunas identity e a propriedade Not For Replication

Ao clicar no combo da propriedade identity no Enterprise Manager, nos deparamos com 3 possibilidades ( ver Figura-2):

 PauloRibeiro_Identity_PtI-Fig02.png

Figura 2. Possibilidades para a coluna identity

<!--[if !supportLists]-->·         <!--[endif]-->Yes: ativa a propriedade identity

<!--[if !supportLists]-->·         <!--[endif]-->No: desativa – não seleciona – a propriedade identity para essa coluna

<!--[if !supportLists]-->·         <!--[endif]-->Yes (Not for Replication) : ativa a propriedade identity, e, se num futuro essa tabela participar de um processo de replicação como publicador de uma replicação Merge, ativará também o controle dos ranges de identity nos subscribers (veja Nota 1).

 

Nota 1. Como funciona o Not For Replication em replicações

Quando ocorre uma inserção numa tabela objeto de replicação merge, essa inserção deverá ser propagada para todos os participantes da publicação. A questão é que o identity gerado no publicador deverá ser mantido no subscriber (e vice-versa): quando o pedido de número 100 for gerado no publicador, deverá ser transferido para o subscriber com o mesmo número, ou seja: o subscriber deve “aceitar”a informação do número do pedido quando a inserção for acionada por um agente de replicação, mas deverá “gerar seu próprio número” para inserções locais. Quando a propriedade Not For Replication estiver ativa, no momento da criação da replicação merge poderemos ainda determinar “ranges” para que nunca existam conflitos na geração do valor do identity entre os participantes da replicação. Por exemplo, poderiamos determinar que o Local-A manipule os identitys na faixa de 1 até 10.000, o local-B de 10.001 até 20.000 e assim por diante. Quando os limites forem atingidos, pode-se determinar o “salto” para que o agente de replicação obtenha a próxima faixa válida (em nosso exemplo, poderíamos definir o salto como 20.000 – quando o local-A atingir o pedido de número 10.000, o próximo pedido iniciará a nova faixa em 10.000+20.000=30.000).

Conclusão

A propriedade identity é uma maneira segura de gerar um número inteiro auto-incrementável, sendo bastante útil para utilização em PK’s e relacionamentos. Em nosso próximo encontro continuaremos esse assunto com diversos exemplos práticos ;

Até lá !

Leia todos artigos da série

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Ficou com alguma dúvida?