none
Alteração de Tabelas RRS feed

  • Pergunta

  • Gostaria de saber se temos a possibilidade de adicionar uma coluna de maneira ordenada em uma tabela

    Ex: criei a seguinte tabela

          CREATE TABLE CLIENTES

                (ID VARCHAR(4) NOT NULL,

                NOME VARCHAR(30) NOT NULL,
                PAGAMENTO DECIMAL(4,2) NOT NULL); 

    teria como eu adicionar uma coluna CODIGOCLI VARCHAR(6) NOT NULL

    apos a coluna ID

    Hoje para fazer este tipo de alteração eu estou utilizando o Enterprise Manager o que torna a manutenção mais lenta, gostaria de montar uma query para enviar para outra pessoal executar pelo Query Analyzer

    Obrigado por enquanto!

    terça-feira, 6 de março de 2007 12:08

Respostas

  • Olá,

    Essa tipo de alteração que você está fazendo, não pode ser aceita por nenhum DBA.

    Deixar as colunas em forma ordenada dessa forma pode ser feito somente no Modelo de Dados de uma ferramenta Case.

    Não existe motivo para fazer isso, quando você escreve comandos de SELECT, UPDATE ou INSERT você coloca as colunas na ordem que você achar melhor.

    A única coisa que isso gera é um aumento do trabalho administrativo, como você citou que já está tendo, e também possiveis problemas de perda de dados.

    Em resumo, esquece...tenha uma boa documentação do seu modelo de dados que é melhor.

    terça-feira, 6 de março de 2007 16:22

Todas as Respostas

  • Denilson,

    Quando se cria uma coluna dentro de uma table, esta coluna recebi um número que determinada a sua ordenação, mas isso é definido pelo SQL Server, sendo que estas informações ficam armazenadas em syscolumns.

    Ao meu ver isso poderia até ser feito, mas seria necessário manipular os dados nas system tables, isso pode ser perigoso.

     

    terça-feira, 6 de março de 2007 12:19
  • e arriscado mais segue


    drop table exemplo
     Create Table Exemplo (campo int, campo2 int)

     alter table exemplo add campo1 int


    GO
    sp_configure 'allow updates', 1
    GO
    RECONFIGURE WITH OVERRIDE
    GO

    Declare @ID int
    Select @ID = id from sysobjects where name = 'exemplo' and xtype = 'U'

    Update Syscolumns Set colid = 4 where name = 'campo2' and id = @id
    Update Syscolumns Set colid = 2 where name = 'campo1' and id = @id
    Update Syscolumns Set colid = 3 where name = 'campo2' and id = @id

    sp_configure 'allow updates', 0
    GO
    RECONFIGURE WITH OVERRIDE
    GO

    Select * From Exemplo


     

    muito cuidado ao dar update em tabelas de sistema, o mais correto seria copiar o script do enterprise manager e rodar depois em separado.

     

    Abs;

    terça-feira, 6 de março de 2007 12:21
  • Denilson completando a resposta dos colegas se não me engano no SQL Server 2005 isso não será mais possível, então seria mais interessante utilizar um novo esquema, como por exemplo copiar os dados para uma tabela temporária e recriar a tabela.

     

     

    Boa sorte

     

    Espero ter ajudado

    terça-feira, 6 de março de 2007 12:39
  • Anderson,

    Isso mesmo, o SQL Server 2005 não permite pois as system tables agora trabalham como se fossem views.

    terça-feira, 6 de março de 2007 12:52
  • Olá,

    Essa tipo de alteração que você está fazendo, não pode ser aceita por nenhum DBA.

    Deixar as colunas em forma ordenada dessa forma pode ser feito somente no Modelo de Dados de uma ferramenta Case.

    Não existe motivo para fazer isso, quando você escreve comandos de SELECT, UPDATE ou INSERT você coloca as colunas na ordem que você achar melhor.

    A única coisa que isso gera é um aumento do trabalho administrativo, como você citou que já está tendo, e também possiveis problemas de perda de dados.

    Em resumo, esquece...tenha uma boa documentação do seu modelo de dados que é melhor.

    terça-feira, 6 de março de 2007 16:22
  • concordo plenamente apesar de possivel e muito arriscado e o risco neste caso nao vale a pena

     

    Abs/;

    terça-feira, 6 de março de 2007 16:49
  •  

    Por isso, destaquei que é um procedimento arriscado e perigoso!!!

    Nós aqui no Fórum devemos também salientar que determinadas situações podem ser muito prejudiciais ao SQL Server, e por conseqüência á nós mesmos.

    terça-feira, 6 de março de 2007 17:21