Solucionado
O professor fala no vídeo que ao fazer o INSERT usando SELECT é necessário usar alias para deixar o nome dos campos do SELECT iguais aos do INSERT, porém isso é dispensável, só devemos ter o cuidado de colocar os campos na mesma ordem para não ocorrer conflito de tipos de dados ao tentar inserir Nome num campo de Data por exemplo. Não usei os mesmos nomes, e o INSERT funcionou corretamente. Fica minha sugestão de correção da aula para que isso fique claro para os outros alunos do curso.
Olá Bruno!
Realmente funciona sim, é um pouco semelhante ao que acontece quando vamos fazer a importação dos dados a partir de um arquivo externo, tipo um arquivo CSV, lá os campos também não são idênticos, só que eles precisam estar na mesma ordem de correspondência justamente para evitar conflitos entre os tipos de dados de cada campo. Porém, como o professor mesmo fala "pra garantir que funcione" é interessante colocarmos os alias nos campos e acordo com os nomes dos campos da tabela de destino. Também acho que uma dica deve ser levada em consideração no mundo real, é interessante não deixarmos brechas para erros, e acho importante colocarmos os alias para não deixar nenhuma brecha para uma possível falha, que poderia gerar sérios problemas aos envolvidos.
Espero que tenha ajudado!
Oi Jonilson! Mas no mundo real, muitas vezes temos tabelas com mais de 100 campos, ter que digitar todos no INSERT só para corresponder no SELECT fica absurdo demais. A não ser que tenha uma alternativa à digitação.
Bruno, eu acho que pode ter sim tabelas grandes, mais não a esse ponto, porque isso quebra todos os princípios de normalização de bancos, cujo um principio básico é que é melhor ter mais tabelas menos campos em cada uma. Assim você elimina possíveis redundâncias na base dados, deixa mais fácil para futuras manutenções e adaptações como também deixa a mesma mais eficiente. Sobre essa parte de normalização você pode dar uma olhada melhor nesse artigo aqui, ele fala sobre a necessidade de normalização na modelagem de banco de dados, bem como as 4 formas normais. Assim, ainda vejo como interessante colocar os alias nos campos quando necessário.
O que acontece é que para o INSERT o que é levado em conta é a ordem dos campos na operação. Colocar alias não significa nada para a engine do SGBD, pode auxiliar visualmente pra nós, mas não garante integridade. Por isso acho errado afirmar: "pra garantir que funcione".
Me ajuda em outra questão! Tenho uma dúvida aberta aqui no fórum sobre Script Update OR Insert.
Claro que ajudo, manda o link pra eu poder localizar, por favor!
Entendo seu pensamento, vou passar para o pessoal avaliar junto ao professor.
Oi Jonilson! Desculpe pela demora, o link da minha outra dúvida é: https://cursos.alura.com.br/forum/topico-script-update-or-insert-91073
Certo, verifiquei lá, bem nesse caso, quando você fala "O que você sugere como alternativa? Tem alguma forma no SQL Server de fazer um backup dos registros que vou dar um Update?", você se refere a criação arquivos de scripts SQL diretamente do SQL server é isso? Bem, se for isso, então você pode tentar usar a opção Gerar Scripts..., para isso bastar clicar com o botão direito do mouse sobre o banco de dados, e depois ir na opção Tarefas e depois em Gerar Scripts... como na imagem:
Em seguida, selecionar a tabela e na próxima:
E depois selecionar a opção avançado:
E em seguida, ir no campo Tipos de dados dos quais gerar script e então selecionar a melhor opção pra você, ou Esquema e dados ou então Somente dados:
E por fim é só concluir o processo.
Fala pra gente se ajudou!
Jonilson, fiz um teste gerando esse script e só foi gerado o script CREATE da tabela. Queria saber se existe um script no SQL Server que seja equivalente ao INSERT or UPDATE que existe no Firebird. Esse script do firebird faz um "backup" das linhas da tabela.
Estranho Bruno, porque com esse procedimento que mencionei eu consegue gerar os scripts sem grandes problemas, e o resultado foi:
USE [SUCOS_VENDAS]
GO
/****** Object: Table [dbo].[TABELA DE CLIENTES] Script Date: 08/06/2020 19:40:05 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[TABELA DE CLIENTES](
[CPF] [varchar](11) NOT NULL,
[NOME] [varchar](100) NULL,
[ENDERECO 1] [varchar](150) NULL,
[ENDERECO 2] [varchar](150) NULL,
[BAIRRO] [varchar](50) NULL,
[CIDADE] [varchar](50) NULL,
[ESTADO] [varchar](2) NULL,
[CEP] [varchar](8) NULL,
[DATA DE NASCIMENTO] [date] NULL,
[IDADE] [smallint] NULL,
[SEXO] [varchar](1) NULL,
[LIMITE DE CREDITO] [money] NULL,
[VOLUME DE COMPRA] [float] NULL,
[PRIMEIRA COMPRA] [bit] NULL,
CONSTRAINT [PK_CLIENTES] PRIMARY KEY CLUSTERED
(
[CPF] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
INSERT [dbo].[TABELA DE CLIENTES] ([CPF], [NOME], [ENDERECO 1], [ENDERECO 2], [BAIRRO], [CIDADE], [ESTADO], [CEP], [DATA DE NASCIMENTO], [IDADE], [SEXO], [LIMITE DE CREDITO], [VOLUME DE COMPRA], [PRIMEIRA COMPRA]) VALUES (N'123123123', N'JOÃO MACHADO', N'RUA PROJETADA A', NULL, N'MADUREIRA', N'Rio de Janeiro', N'RJ', N'20000', CAST(N'2000-03-06' AS Date), 19, N'M', 120000.0000, 120000, 1)
INSERT [dbo].[TABELA DE CLIENTES] ([CPF], [NOME], [ENDERECO 1], [ENDERECO 2], [BAIRRO], [CIDADE], [ESTADO], [CEP], [DATA DE NASCIMENTO], [IDADE], [SEXO], [LIMITE DE CREDITO], [VOLUME DE COMPRA], [PRIMEIRA COMPRA]) VALUES (N'1471156710', N'Érica Carvalho', N'R. Iriquitia', N'', N'Jardins', N'São Paulo', N'SP', N'80012212', CAST(N'1990-09-01' AS Date), 29, N'F', 170000.0000, 24500, 0)
<Restante do conteúdo>Então você colocou a opção Somente dados?
Obrigado Jonilson! Não tinha me atentado a essa última opção... por padrão o SSMS estava trazendo a opção "Esquema somente", então mudei para "Esquema e dados" e deu certo.