Tabela com erro/mudança e com dados - Fórum DevMedia
Tabela com erro/mudança e com dados
- 10 out 2014
Quando nós temos uma tabela e a mesma já com contenha uma grande quantidade de dados, se for necessario inserir mais um campo, qual o procedimento correto? alter table?
Se o campo for no fim da tabela mesmo, não vejo problema.
A não ser que o campo seja NOT NULL, se ele for NOT NULL terá que ter pelo menos um valor DEFAULT.
Por exemplo: ALTER TABLE Table ADD Campo VARCHAR(50) NOT NULL DEFAULT ''.
Mas se o campo tiver que ficar no meio da tabela, aí o que eu faço é criar uma tabela temporária copiando os campos e valores da tabela antiga, excluo a tabela antiga e crio ela novamente inclunido o campo novo onde desejo, e depois copio os registros da tabela temporária e depois a excluo.
Como assim no meio da tabela?
poderia me explicar, com codigo, como posso fazer essa tabela temporaria e copiar os dados?
Então, vamos supor que eu tenho a tabela Cliente no banco de dados com a seguinte estrutura...
RAZAOSOCIAL VARCHAR(30) NOT NULL,
CNPJ VARCHAR(14) NOT NULL
Daí agora eu quero incluir o campo NOMEFANTASIA.
Se o campo NOMEFANTASIA pode ficar depois do CNPJ, tudo bem. Eu simplesmente coloco o seguinte:
ALTER TABLE CLIENTE ADD NOMEFANTASIA VARCHAR(30) NULL
Posso até pra não ficar em branco, cadastrar o nomefantasia igual a RAZAOSOCIAL
UPDATE CLIENTE SET NOMEFANTASIA = RAZAOSOCIAL
Mas já trabalhei em uma empresa que a ordem dos campos na tabela influenciava no software e o campo NOMEFANTASIA tinha que aparecer depois da RAZAOSOCIAL e antes do CNPJ. Daí eu criava uma tabela temporária copiando a tabela Cliente
SELECT * INTO dbo.Tmp_Cliente FROM Cliente -- Esse comando cria a tabela Tmp_Cliente copiando todos os campos e registros da tabela Cliente.
NOMEFANTASIA VARCHAR(30) NOT NULL,
INSERT INTO CLIENTE (CODIGO, RAZAOSOCIAL, NOMEFANTASIA, CNPJ)  SELECT CODIGO, RAZAOSOCIAL, RAZAOSOCIAL, CNPJ FROM TMP_CLIENTE
DROP TABLE TMP_CLIENTE
Importante que a tabela não tenha integridade, caso tenha, terá que excluir as integridades antes e incluir no final.
Deu pra entender? Esse recurso me ajuda muito.
Obrigada, vamos ver se eu entendi, no primeiro comando ele cria uma tabela provisoria e os seus dados e em seguida apago a que vou mudar, não corre risco de dar problema?
Primeiro você deve criar o novo atributo sem definir que o preenchimento dele seja obrigatório.
Se o preenchimento desse campo na tabela não for obrigatório ele pode permanecer assim que não haverá problemas, pois o usuário pode incluir informações nesse campo através do formulário de alterações de dados no sistema.
Senão, se o preenchimento do campo for obrigatório, você terá que preencher todos os registros da tabela com um valor default ou conforme a regra de negócio que a criação desse campo está atendendo. Depois de ter todos os registros com a informação preenchida é só alterar as propriedades dessa coluna e
Depois de ter todos os registros com a informação preenchida é só alterar as propriedades dessa coluna definir ele como obrigatório.
Ao meu ver, não tem necessidade de criar tabela temporária...
Já fiz isso da forma que descrevi e não tive problema nenhum e eu acho até que é bem mais prático.
Minha sugestão de tabela temporária é apenas se o campo novo necessitar de ser inserido no meio da tabela no banco de dados.
Entendi Wanderson!
Eu não tinha lido tua ultima postagem, pois a pagina não tava atualizada....
Mas a ordem que os campos são inseridos na tabela só vai influenciar se as clausulas GROUP BY estiverem definidas na ordem errada ou se os desenvolvedores utilizam SELECT * FROM.
OBS.: SELECT * FROM não é uma boa prática de programação SQL.
É que onde eu trabalhei, usávamos frameworks internos para auxiliar no desenvolvimento automatizando várias funções do sistema.
Então para o bom funcionamento do framework, um dos requisitos era que os campos de cadastro no formulário da tela, deveriam estar na mesma ordem dos campos na tabela no banco de dados.
Eu nem gostava muito do framework mas era obrigado a usar, então usei muito esse recurso quando precisava inserir algum campo novo.
Será que isso funciona nos principais SGBDs? Sempre vejo suas postagens Marisiana relacionado ao Oracle, sua especialidade.
- 13 out 2014
Embora eu não conheça todos os principais bancos de dados, eu acredito que sim, pois todos os SGBDs possuem como base a liguagem SQL nativa então muitas coisas são aplicadas a todos de forma igual. É como se SQL fosse a metodologia dos SGBDs, pois o que muda de um pra outra é a sintaxe e os recursos que há em um e no outro não.