Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da SQL Magazine DIGITAL
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Alterando chaves primárias em ambiente de produção - Artigo Revista SQL Magazine 87
Desenvolvimento de soluções para problemas cotidianos enfrentados por DBAs e desenvolvedores de aplicações para banco dados.
[fechar]
Você não gostou da qualidade deste conteúdo?
(opcional) Você gostaria de comentar o que não lhe agradou?
SQL Magazine 87
[Artigo disponível no Leitor Digital DevMedia. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da SQL Magazine 87
[Artigo disponível no Leitor Digital DevMedia. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da SQL Magazine 87
Alterando chaves primárias em ambiente de produção
Existem muitas tarefas que executamos nos bancos de dados que escondem sua complexidade. Coisas que a primeira vista parecem triviais e, quando vamos executá-las, percebemos a necessidade de realizar também uma série de ações complementares que ninguém havia previsto.
Uma destas tarefas aparentemente triviais é a alteração da chave primária de uma tabela. Quando temos que realizar tal alteração, é comum vir um pensamento na cabeça: “é para isso que existe a declaração ALTER TABLE”.
Pode ser até que você já tenha passado por alguma experiência em que executou declarações semelhantes em ambiente de desenvolvimento e que não gastou mais do que 30 minutos entre planejamento, criação dos scripts e implementação.
OK, em ambiente de desenvolvimento as coisas costumam ser simples. As tabelas alteradas podem estar vazias ou então simplesmente contem dados que podem ser perdidos sem nenhum problema. Daí, basta escrever a declaração SQL!
Entretanto, não é assim em ambiente de produção. Em primeiro lugar, o cargo de DBA existe exatamente para garantir a segurança dos dados das nossas empresas. Com estas palavras nos referimos não apenas à segurança de acesso aos dados, evitando que pessoas não autorizadas possam ler/alterar dados do banco, mas também à segurança contra a perda de dados.
Neste artigo, apresento alguns cenários em que precisamos alterar chaves primárias em tabelas de produção... e claro, algumas estratégias usadas para realizar esta tarefa.
Exigências das Chaves Primárias
As chaves primárias são de extrema importância nas nossas tabelas. Em primeiro lugar, é boa prática que toda tabela tenha uma chave primária definida. A chave primária garante a existência de um identificador único na tabela, ou seja, não existirão dois registros na tabela que contenham o mesmo valor nos campos que compõe esta chave.
A PK pode ser simples, ou seja, baseada em um único campo, ou então composta, quando inclui vários campos. Por definição, uma tabela pode ter apenas uma chave primária (veja Nota DevMan 1).
Nota DevMan 1 – Escolhendo a Chave Primária e Chave Alternativa
Eventualmente, pode existir numa tabela mais de um campo ou conjunto de campos que seja um possível candidato a chave primária. Todos estes campos são chamados de chaves candidatas, mas apenas um deles será chave primária. E todas as demais, aquelas que não forem escolhidas, serão chamadas de chaves alternativas.
"
Este é um post disponível para assinantes MVP
Existem muitas tarefas que executamos nos bancos de dados que escondem sua complexidade. Coisas que a primeira vista parecem triviais e, quando vamos executá-las, percebemos a necessidade de realizar também uma série de ações complementares que ninguém havia previsto.
Uma destas tarefas aparentemente triviais é a alteração da chave primária de uma tabela. Quando temos que realizar tal alteração, é comum vir um pensamento na cabeça: “é para isso que existe a declaração ALTER TABLE”.
Pode ser até que você já tenha passado por alguma experiência em que executou declarações semelhantes em ambiente de desenvolvimento e que não gastou mais do que 30 minutos entre planejamento, criação dos scripts e implementação.
OK, em ambiente de desenvolvimento as coisas costumam ser simples. As tabelas alteradas podem estar vazias ou então simplesmente contem dados que podem ser perdidos sem nenhum problema. Daí, basta escrever a declaração SQL!
Entretanto, não é assim em ambiente de produção. Em primeiro lugar, o cargo de DBA existe exatamente para garantir a segurança dos dados das nossas empresas. Com estas palavras nos referimos não apenas à segurança de acesso aos dados, evitando que pessoas não autorizadas possam ler/alterar dados do banco, mas também à segurança contra a perda de dados.
Neste artigo, apresento alguns cenários em que precisamos alterar chaves primárias em tabelas de produção... e claro, algumas estratégias usadas para realizar esta tarefa.
Exigências das Chaves Primárias
As chaves primárias são de extrema importância nas nossas tabelas. Em primeiro lugar, é boa prática que toda tabela tenha uma chave primária definida. A chave primária garante a existência de um identificador único na tabela, ou seja, não existirão dois registros na tabela que contenham o mesmo valor nos campos que compõe esta chave.
A PK pode ser simples, ou seja, baseada em um único campo, ou então composta, quando inclui vários campos. Por definição, uma tabela pode ter apenas uma chave primária (veja Nota DevMan 1).
Nota DevMan 1 – Escolhendo a Chave Primária e Chave Alternativa
Eventualmente, pode existir numa tabela mais de um campo ou conjunto de campos que seja um possível candidato a chave primária. Todos estes campos são chamados de chaves candidatas, mas apenas um deles será chave primária. E todas as demais, aquelas que não forem escolhidas, serão chamadas de chaves alternativas.
"
A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da SQL Magazine DIGITAL
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Wagner Crivelini
Atua a mais de 15 anos na área TI, particularmente com Business Intelligence. Engenheiro formado pela UNICAMP, trabalha na IBM na unidade de IBM Global Account onde atua como DBA DB2 e SQL SERVER em projetos internacionais. Profissional com várias certificações em DB2, entre elas IBM Certified Sol...
O que você achou deste post?
Cursos relacionados
Publicidade
