Convertidor de CSV a SQL
Sube un archivo CSV o pega datos para convertirlos en sentencias SQL INSERT
Arrastra un archivo CSV aquí o haz clic para seleccionar
¿Qué es CSV a SQL?
CSV a SQL es una herramienta en línea de conversión de formatos de datos que convierte datos en formato CSV (valores separados por comas) en sentencias SQL INSERT para facilitar la importación a bases de datos.
CSV es un formato de datos tabulares común, ampliamente utilizado en hojas de cálculo y exportación de datos. SQL es el lenguaje de consulta estándar para bases de datos relacionales, y las sentencias INSERT se utilizan para insertar datos en tablas de bases de datos.
Con esta herramienta, puedes convertir rápidamente datos CSV en sentencias SQL ejecutables, con soporte para nombres de tabla personalizados, nombres de campos y estilos de comillas para facilitar las operaciones de migración e importación de datos.
Cómo usar
Cómo usar
- Pega o introduce datos CSV en el cuadro de entrada, o sube un archivo CSV
- Configura el nombre de la tabla (por defecto es table_name)
- Selecciona el delimitador adecuado (por defecto es la coma)
- Elige si usar la primera fila como nombres de campos
- Las sentencias SQL INSERT se generarán a la derecha
Seguridad en la importación
- Revisa las sentencias INSERT generadas en cuanto a nombre de tabla, orden de columnas, escapado de caracteres, valores NULL y formatos numéricos antes de ejecutarlas.
- Ejecuta primero un lote pequeño y envuelve las importaciones reales en una transacción cuando tu base de datos lo permita.
Casos de uso
Principio técnico
La entrada CSV se analiza con una máquina de estados conforme al RFC 4180 (manejando campos entrecomillados, comillas dobles escapadas y finales de línea CRLF/LF), y luego se emite como sentencias SQL INSERT estándar ANSI. Las dos gramáticas no se superponen: CSV usa duplicación de comillas dobles para el escape ("O""Brien"), mientras que SQL usa duplicación de comillas simples dentro de literales de cadena ('O''Brien') según ISO/IEC 9075. El convertidor reescribe cada apóstrofo interno a un par duplicado antes de envolver el valor en comillas simples, que es el único mecanismo de escape garantizado en MySQL, PostgreSQL, SQLite, SQL Server y Oracle. Las comillas de identificadores son específicas del dialecto: MySQL usa acentos graves `users`, PostgreSQL y SQL Server usan comillas dobles "users" (sensible a mayúsculas cuando se entrecomilla) y SQLite acepta ambos: elige el estilo que coincida con el motor destino para evitar errores de "columna desconocida" causados por el cambio de mayúsculas. La inferencia de tipos es intencionalmente mínima porque CSV no tiene metadatos de tipo. El borrador opcional de CREATE TABLE emite VARCHAR(255) para cada columna - seguro pero subóptimo - y deja al usuario la sustitución por INT, BIGINT, DECIMAL(p,s), DATE, TIMESTAMP o TEXT antes de ejecutar en producción. Las celdas vacías se emiten como NULL (el marcador de ausencia de la lógica de tres valores de SQL) en lugar de como la cadena vacía '', porque la mayoría de las exportaciones de hojas de cálculo usan un campo en blanco para representar datos faltantes; si la distinción de cadena vacía importa, cambia a un cargador tipado en su lugar. Las palabras reservadas como user, order y group NO se entrecomillan automáticamente, por lo que una columna llamada literalmente order fallará al analizarse en MySQL a menos que el usuario la envuelva en acentos graves manualmente. Para importaciones grandes, las sentencias INSERT de una sola fila son correctas pero lentas: el max_allowed_packet predeterminado de MySQL es 64 MB y un INSERT INTO t VALUES (...), (...) en lotes de ~1000 filas por sentencia es típicamente 5-10x más rápido que una sentencia por fila debido a la sobrecarga de viaje de red y análisis. Envolver el lote en BEGIN; ... COMMIT; permite a la base de datos preparar las inserciones y confirmarlas atómicamente, lo cual es esencial cuando una inserción parcial dejaría una relación de clave foránea inconsistente. Ten en cuenta que esta herramienta no infiere claves foráneas, índices, restricciones de clave primaria ni AUTO_INCREMENT: solo convierte datos de filas, por lo que el esquema receptor debe existir ya o el borrador de CREATE TABLE debe editarse antes de la ejecución. Para cargas masivas de millones de filas, prefiere la sintaxis nativa de la base de datos: PostgreSQL COPY FROM, MySQL LOAD DATA INFILE o SQL Server bcp.
- Escape de literales de cadena SQL según ISO/IEC 9075: las comillas simples se duplican ('O''Brien'), no se escapan con barra invertida.
- Las comillas de identificadores difieren: ` para MySQL, " para PostgreSQL/SQL Server, ambos aceptados en SQLite.
- Celda CSV vacía -> SQL NULL (lógica de tres valores), no '' - la distinción de cadena vacía se pierde.
- Las palabras reservadas (order, user, group) no se entrecomillan automáticamente; se requiere escape manual.
- Lotes de INSERT multi-fila de ~1000 filas alcanzan ~5-10x de rendimiento frente a sentencias de una sola fila (MySQL max_allowed_packet 64 MB por defecto).
- Envolver con BEGIN; ... COMMIT; para inserciones semilla atómicas; los fallos parciales revierten limpiamente.
- Cargas masivas de más de 1M de filas: preferir PostgreSQL COPY, MySQL LOAD DATA INFILE, SQL Server bcp sobre INSERTs generados.
Ejemplos
CSV básico -> sentencias INSERT (estilo MySQL con backticks)
CSV:
id,name,email
1,Alice,alice@example.com
2,Bob,bob@example.com
SQL:
INSERT INTO `users` (`id`, `name`, `email`) VALUES (1, 'Alice', 'alice@example.com');
INSERT INTO `users` (`id`, `name`, `email`) VALUES (2, 'Bob', 'bob@example.com');Con CREATE TABLE (estilo PostgreSQL con comillas dobles)
CSV:
product_id,price,in_stock
101,29.99,true
102,15.50,false
SQL:
CREATE TABLE "products" (
"product_id" VARCHAR(255),
"price" VARCHAR(255),
"in_stock" VARCHAR(255)
);
INSERT INTO "products" ("product_id", "price", "in_stock") VALUES ('101', '29.99', 'true');
INSERT INTO "products" ("product_id", "price", "in_stock") VALUES ('102', '15.50', 'false');
-- Consejo: cambie VARCHAR(255) a INT / DECIMAL(10,2) / BOOLEAN antes de ejecutarlo en producción.Escape de comillas simples dentro de los valores
CSV:
id,note
1,O'Brien signed off
2,It's already done
SQL:
INSERT INTO `notes` (`id`, `note`) VALUES (1, 'O''Brien signed off');
INSERT INTO `notes` (`id`, `note`) VALUES (2, 'It''s already done');
Nota: las comillas simples se duplican (''), que es el escape estándar de SQL.Inferencia de tipos - INT vs DECIMAL vs TEXT
CSV:
user_id,score,bio
1,100,Hello
2,87.5,Long bio text...
Tipos detectados (heurística):
user_id -> INT
score -> DECIMAL(10,2)
bio -> VARCHAR(255) (considere TEXT para contenido más largo)
Vista previa SQL:
INSERT INTO `students` (`user_id`, `score`, `bio`) VALUES (1, 100, 'Hello');
INSERT INTO `students` (`user_id`, `score`, `bio`) VALUES (2, 87.5, 'Long bio text...');Preguntas frecuentes
¿Qué tipo de SQL genera la herramienta?
Produce sentencias estándar CREATE TABLE más INSERT INTO. El dialecto es SQL portable por defecto: funciona en MySQL, PostgreSQL, SQLite y MSSQL con pequeños ajustes de tipo. Algunas páginas te permiten elegir un dialecto de destino para los tipos de datos (VARCHAR vs TEXT, INT vs INTEGER, etc.).
¿De dónde salen los nombres de columna?
De la primera fila del CSV cuando «la primera fila es cabecera» está activado. La página sanea los nombres reemplazando los espacios por guiones bajos y entrecomillando las palabras reservadas. Sin cabeceras, las columnas se llaman col_1, col_2, etc.
¿Cómo se infiere el tipo de dato de cada columna?
La página muestrea valores y elige el tipo más estrecho que encaje: INTEGER si toda celda es un número entero, DECIMAL si hay fraccionarios, VARCHAR(N) ajustado a la celda más larga, BOOLEAN para true/false, DATE/DATETIME para strings en formato ISO. Puedes anular el tipo inferido antes de generar el SQL.
¿Qué pasa con las comillas y los caracteres especiales en los datos?
Las comillas simples dentro de cadenas se escapan duplicándolas (O'Brien → 'O''Brien'). Las barras invertidas y los caracteres Unicode se pasan literalmente: esto coincide con el comportamiento de PostgreSQL con standard_conforming_strings = on. Verifica el resultado contra el modo NO_BACKSLASH_ESCAPES de MySQL si tu destino es MySQL.
¿Por qué los NULLs son distintos de las cadenas vacías?
Una celda CSV vacía (p. ej. 'a,,c') se convierte en SQL NULL; una cadena vacía entrecomillada ('a,"",c') se convierte en ''. La página sigue esa convención. Desactiva «tratar vacíos como NULL» si necesitas conservar la cadena vacía en ambos casos.
¿Se suben mis datos a algún servidor?
No. El CSV se parsea y el SQL se genera en tu navegador. La entrada y la salida no salen de la página. Usa el resultado como un script SQL que importas tú mismo a tu servidor de base de datos.
¿Debería usar el SQL generado en una base de datos de producción?
Revísalo primero. La sentencia CREATE TABLE puede no coincidir con tu esquema actual; los INSERT no incluyen restricciones, claves foráneas ni índices. Úsalo como punto de partida para editar, sobre todo claves primarias, restricciones NOT NULL y tipos de datos adecuados.