Converter XLSX para SQL

A saída é um arquivo de comandos INSERT, um por linha da planilha, cada um nomeando a tabela e listando as colunas do cabeçalho. Não há CREATE TABLE no topo, e isso é deliberado: uma planilha não tem tipos, tamanhos, chaves nem restrições.

Um palpite errado numa linha é um registro ruim. Um palpite errado num schema é um VARCHAR(50) que trunca endereços por dois anos. A premissa aqui é que você já desenhou a tabela — verdade para quase todo mundo que precisa desta conversão.

O nome do arquivo, sem a extensão, vira a tabela em todo comando. É sanitizado primeiro: qualquer coisa que não seja letra, dígito ou sublinhado vira sublinhado, e um nome começando com dígito recebe um prefixo.

O conselho prático segue direto disso. Renomeie o arquivo exatamente para a tabela em que você vai carregar antes de converter, e a saída roda como está. A mesma sanitização se aplica aos nomes de coluna do cabeçalho.

Números são escritos sem formatação. Texto é envolvido em aspas simples com qualquer apóstrofo interno dobrado, a forma ANSI que todo motor grande entende — "O apóstrofo" vira 'O''apóstrofo'. Escape com barra invertida deliberadamente não é usado.

Uma célula vazia vira a palavra-chave NULL em vez de uma string vazia, quase sempre a leitura certa de um espaço em branco numa planilha.

Uma célula booleana é escrita como o literal TRUE ou FALSE. Postgres aceita isso diretamente, MySQL trata como sinônimos de 1 e 0, e SQLite aceita há anos. SQL Server não: seu tipo bit quer 1 e 0.

É um ajuste de dois segundos quando você sabe, e vinte minutos irritantes se você descobrir por um erro no comando quatrocentos. Se o destino é SQL Server, faça a substituição primeiro.

Uma planilha guarda uma data como uma contagem de dias vestida com um formato de exibição, e a conversão escreve o valor em vez da aparência. 1º de janeiro de 2024 vira 45292.

Inserido numa coluna numérica isso entra quieto e errado; inserido numa coluna de data é rejeitado. Conserte na planilha convertendo a coluna para texto num formato sem ambiguidade, ou carregue numa coluna de preparação e converta dentro do banco.

Um código guardado como texto na planilha é escrito como string entre aspas, então 007 chega como '007' e um CEP com zero à esquerda entra intacto numa coluna VARCHAR.

O teste útil para saber se uma coluna é um identificador é se somar dois de seus valores significaria algo. CEP, código de peça, telefone e CPF falham todos nesse teste — e todos pertencem numa coluna de texto no destino também.

Todo comando nomeia suas colunas explicitamente em vez de depender da ordem da tabela, o que faz o arquivo sobreviver a uma tabela que ganhou uma coluna depois. O conjunto de colunas é a união dos campos encontrados em toda a planilha.

Essa verbosidade tem um custo: a lista de colunas se repete em cada linha, então o arquivo fica maior que o dado nele. Cinquenta mil linhas de seis colunas saíram em cerca de 5,7 MB de SQL contra 4,3 MB do .xlsx original.

Os comandos são emitidos um por linha sem transação ao redor. Rodado assim contra Postgres ou MySQL, isso é cinquenta mil idas e voltas ao banco e cinquenta mil commits implícitos.

Envolver o arquivo em BEGIN e COMMIT resolve os dois problemas de uma vez e custa duas linhas. Para cargas genuinamente grandes, a ferramenta melhor é o caminho de carga em massa — COPY no Postgres, LOAD DATA no MySQL.

A primeira planilha do arquivo é o que vira os comandos, porque uma sequência de INSERTs endereça uma tabela. Se a planilha que você quer não é a primeira, mova-a e converta de novo.

Tudo isso acontece localmente: a planilha é lida e os comandos são escritos na página, sem upload. Isso importa mais neste par do que na maioria, já que uma planilha a caminho de um banco de dados costuma ser registros de clientes ou transações.