Converter CSV para SQL

Vale dizer isso antes de qualquer coisa, porque para boa parte de quem procura essa conversão a resposta é que não precisa dela. Postgres tem COPY, MySQL tem LOAD DATA INFILE, SQLite tem .import, SQL Server tem BULK INSERT, e todos leem um arquivo delimitado direto, aplicam os tipos de coluna de uma vez e gravam em blocos. Acima de poucos milhares de linhas, esse caminho ganha de longe de um arquivo de comandos INSERT.

O que torna esta conversão a escolha certa é uma restrição, não uma preferência. O carregador em massa precisa que o arquivo esteja em algum lugar que o servidor alcance, e muitas vezes exige um privilégio que a conta não tem. Se tudo que você tem é uma janela de consulta — um console de banco gerenciado, uma ferramenta de migração, um chamado que outra pessoa vai executar — os comandos são a única moeda disponível, e gerar isso na mão para quatrocentas linhas é um jeito ruim de gastar uma tarde.

A saída é um arquivo de comandos INSERT, um por linha de dado, cada um nomeando a tabela e listando as colunas tiradas do cabeçalho. Nada vem antes deles. É uma recusa, não um esquecimento: um CSV não registra tipo, tamanho, chave nem obrigatoriedade, então um esquema gerado a partir dele seria um chute apresentado com a autoridade de um comando DDL.

O custo de um chute errado é desproporcional. Uma linha ruim é um registro ruim e um DELETE resolve. Um VARCHAR(50) inferido a partir do maior valor de uma amostra trunca endereço por dois anos até alguém notar. A premissa aqui é que você já projetou a tabela, o que vale para quase todo mundo que quer este arquivo, e que o que se quer automatizar é a parte repetitiva. Se você também precisa da tabela, escreva o comando CREATE você mesmo e cole no topo; os comandos gerados rodam sem alteração nenhuma.

O nome do CSV, sem a extensão, é usado como tabela. Ele passa por uma limpeza: qualquer coisa fora letra, dígito e sublinhado vira sublinhado, e um nome começando com dígito recebe um sublinhado na frente, porque um identificador não pode começar com número. Um arquivo chamado `pedidos 2024.csv` gera comandos para `pedidos_2024`.

A mesma limpeza vale para os nomes de coluna tirados do cabeçalho, e é a parte que mais costuma surpreender. Um cabeçalho como `Total do pedido (R$)` vira `Total_do_pedido___R__` e não vai bater com nada na sua tabela. Ajuste o cabeçalho na origem para casar exatamente com as colunas de destino, renomeie o arquivo para o nome da tabela, e o arquivo gerado não precisa de nenhuma edição — vale os dois minutos, porque a alternativa é um localizar-e-substituir em cinquenta mil linhas.

É aqui que converter um CSV difere de converter uma planilha, e é a coisa mais provável de sair errada. Uma célula de planilha sabe se guarda texto ou número. Um campo de CSV é só caractere, então o leitor infere, e o que ele infere é o que o gerador de SQL enxerga: um valor lido como número sai sem aspas, um valor mantido como texto sai entre aspas.

Na prática, colunas de identificador perdem as aspas e o preenchimento ao mesmo tempo. Um CEP como 01234-000 pode virar um número sem os zeros à esquerda; um telefone sem espaços vira um inteiro grande; um código de peça como `1e5` vira `100000`. Inserido numa coluna VARCHAR isso entra como string sem preenchimento e sem erro nenhum, que é o pior resultado possível porque nada reclama. Exporte colunas de identificador com aspas ou com um prefixo não numérico, ou confira o arquivo gerado antes de rodar — ler o primeiro comando leva dez segundos e mostra a tabela, a lista de colunas e um exemplo de cada tipo de valor de uma vez.

Um espaço em branco entre dois delimitadores vira a palavra-chave NULL em vez de uma string vazia. Quase sempre é a leitura certa de uma lacuna numa exportação, e é a leitura que uma restrição NOT NULL vai recusar com um erro claro em vez de aceitar em silêncio, que é o comportamento que se quer.

Onde um espaço em branco realmente significava uma string vazia, o arquivo nunca guardou essa distinção e nenhum conversor consegue recuperá-la. Se a sua tabela tem uma coluna onde "" e NULL significam coisas diferentes — um campo de texto livre opcional, o caso mais comum — registre a diferença no CSV antes de converter, ou trate isso numa etapa intermediária.

Número e booleano saem sem aspas. Texto vem entre aspas simples, com qualquer apóstrofo interno duplicado, então «d'agua» vira `'d''agua'`. É a convenção ANSI, e todo banco relevante lê da mesma forma.

O escape com barra invertida foi deixado de fora de propósito. É uma extensão do MySQL cujo comportamento depende do ajuste de servidor NO_BACKSLASH_ESCAPES, não do comando em si, o que significa que um arquivo usando isso pode rodar certo num servidor e corromper dado em outro com a mesma versão. Duplicar a aspa funciona em qualquer lugar, e o arquivo resultante pode ser versionado e rodado em vários ambientes sem carregar uma suposição sobre nenhum deles.

Um campo lido como `true` ou `false` no CSV é interpretado como booleano e escrito como o literal sem aspas TRUE ou FALSE. Postgres aceita direto, MySQL trata as palavras como apelidos para 1 e 0, e SQLite aceita há anos.

O SQL Server não. O tipo bit dele quer 1 e 0, e um comando com TRUE nem chega a rodar — o que você vai descobrir no primeiro comando se tiver sorte, e no comando de número quatrocentos se a coluna booleana tiver uma sequência de vazios no topo. Se o destino é esse, faça a substituição antes de rodar qualquer coisa, e confira antes se nenhuma coluna de texto por acaso contém a palavra sozinha.

Nada nesta conversão interpreta uma data. Um campo lido como `2024-03-11` não é numérico, então continua string e sai entre aspas, e um campo como `11/03/2024` faz o mesmo. Isso é melhor do que parece: uma data ISO entre aspas entra corretamente numa coluna de data em qualquer um desses bancos, o que torna um CSV bem formado a fonte mais fácil de todas de carregar.

É também onde a ambiguidade atravessa intacta. `11/03/2024` é 11 de março ou 3 de novembro dependendo de quem exportou, e o arquivo não diz qual. O banco vai interpretar de acordo com a própria configuração regional e não vai avisar qual escolheu. Se o CSV veio de um sistema cujo formato de data você não consegue confirmar, carregue numa coluna de texto intermediária e converta de forma explícita depois, onde a suposição fica escrita em vez de herdada.

Os comandos saem individualmente, sem BEGIN, sem COMMIT e sem agrupar vários valores num só VALUES. Rodado assim contra um servidor remoto são cinquenta mil idas e voltas e cinquenta mil confirmações implícitas, o que é lento o bastante para notar e deixa a tabela pela metade se algo falhar no meio do caminho.

Duas linhas resolvem os dois problemas: envolva o arquivo em BEGIN e COMMIT e a carga inteira vira atômica e bem mais rápida. O arquivo também é maior que o dado em si, porque a lista de colunas se repete em cada linha — uma tabela larga com nomes de coluna longos pode gerar um arquivo SQL várias vezes maior que o CSV de origem, o que vale saber antes de mandar por e-mail.

Analisar o arquivo e gerar os comandos são as duas coisas puro JavaScript rodando aqui, então nada é enviado e não existe fila; o que limita o trabalho é o teto de 100 MB por arquivo do plano gratuito e depois a memória do seu computador. Isso pesa especialmente neste par: um CSV a caminho de um banco costuma ser registro de cliente, transação ou lista de correção, e colar isso num site para processar é exatamente o que a Lei Geral de Proteção de Dados existe para evitar.

O teto é a tabela inteira sendo mantida de uma vez, o que deixa dezenas de megabytes confortavelmente dentro do limite. Acima disso, a resposta é o carregador em massa da primeira seção, não um conversor maior, e é uma resposta melhor de qualquer jeito.