Cómo importar un CSV en MySQL y PostgreSQL

Importar un archivo de valores separados por comas a MySQL o PostgreSQL se hace mediante los comandos de carga masiva de cada motor, pero el éxito depende sobre todo de una buena preparación previa, ya que es en los detalles del archivo y de la tabla donde surgen la mayoría de los problemas. El proceso completo consta de varias fases. La primera es la preparación previa, que tiene tres partes fundamentales: crear la tabla de destino con las columnas y los tipos de datos adecuados para los datos que contiene el archivo; revisar cuál es el separador que utiliza el archivo, ya que aunque el formato se llame de valores separados por comas, en la práctica muchos archivos usan punto y coma u otro carácter, especialmente los exportados desde hojas de cálculo en configuraciones regionales donde la coma actúa como separador decimal; y comprobar la codificación del archivo, ya que si no está en la codificación universal, los caracteres especiales como las tildes y las eñes llegarán corruptos a la base de datos. La segunda fase es ejecutar el comando de carga masiva propio de cada motor. En MySQL, el comando es el de carga de datos desde un archivo, mientras que en PostgreSQL es el comando de copia, que tiene además una variante que se ejecuta desde el cliente y que permite importar un archivo local sin necesitar permisos especiales en el servidor, siendo esta variante muy cómoda para importar desde el propio equipo. Estos comandos leen el archivo completo y lo insertan de golpe, lo que es mucho más rápido que insertar los datos fila a fila. Al ejecutarlos hay que indicarles el separador real del archivo, la codificación y si el archivo tiene una primera fila de encabezados con los nombres de las columnas que hay que saltar para no intentar insertarla como datos. La tercera fase, que a menudo se olvida, es manejar los errores en los datos, ya que los archivos del mundo real casi siempre presentan problemas como fechas con formatos inesperados, campos vacíos donde se espera un número, filas con un número incorrecto de columnas o textos con caracteres conflictivos, que pueden hacer que la carga falle o inserte datos incorrectos. Para gestionar esto se recomienda probar primero con una muestra pequeña del archivo y, en casos problemáticos, cargar los datos en una tabla intermedia de columnas de texto, limpiarlos con instrucciones de la base de datos y luego pasarlos a la tabla definitiva. Siguiendo estas fases, la importación resulta fiable y eficiente.

El separador del archivo de valores separados por comas causa muchos problemas porque, a pesar de que el formato se llama de valores separados por comas, en la práctica una gran cantidad de archivos no usan la coma como separador, sino el punto y coma u otro carácter, y si al importar se indica un separador equivocado, la base de datos no interpreta correctamente las columnas y la carga falla o mete todos los datos en un solo campo. El nombre del formato induce a pensar que los valores siempre están separados por comas, pero la realidad es más variada. Un caso muy habitual es el de los archivos exportados desde hojas de cálculo en configuraciones regionales donde la coma se utiliza como separador decimal de los números, es decir, donde los decimales se escriben con coma en lugar de con punto. En esas configuraciones, para evitar la confusión entre la coma decimal y la coma separadora de campos, las hojas de cálculo exportan los archivos usando el punto y coma como separador de campos en lugar de la coma. Otros archivos utilizan el tabulador como separador. El problema surge cuando, al importar el archivo, se le indica al comando de carga que el separador es la coma cuando en realidad el archivo usa punto y coma u otro carácter. En ese caso, la base de datos, al no encontrar comas separando los valores, o al encontrarlas en lugares equivocados, no puede dividir correctamente cada línea en sus columnas, y el resultado es que interpreta toda la línea como una sola columna gigante, o divide mal los datos, lo que hace que la carga falle o que los datos queden mal distribuidos en la tabla. Para evitar este problema, la recomendación es no asumir nunca cuál es el separador, sino comprobarlo abriendo el archivo en un editor de texto plano, y no en una hoja de cálculo, ya que esta última interpreta el archivo y oculta el separador real, mostrando los datos ya organizados en columnas. Al abrir el archivo en un editor de texto se ve el contenido tal cual está guardado, y se puede identificar con qué carácter están separados realmente los valores. Una vez identificado el separador correcto, se le indica al comando de carga, y así la base de datos puede dividir correctamente cada línea en sus columnas. Esta simple comprobación previa del separador evita uno de los tropiezos más frecuentes y frustrantes al importar archivos de este tipo.

Las tildes, las eñes y otros caracteres especiales se rompen al importar un archivo cuando la codificación del archivo no coincide con la que espera la base de datos, mostrándose como símbolos extraños o caracteres sin sentido, y esto ocurre habitualmente cuando el archivo no está guardado en la codificación universal. La codificación es la forma en que se representan los caracteres como secuencias de bytes en un archivo, y existen distintas codificaciones que representan los caracteres de maneras diferentes. La codificación universal es la que se ha establecido como estándar y la que las bases de datos modernas suelen esperar y usar por defecto, ya que puede representar prácticamente todos los caracteres de todos los idiomas. El problema surge cuando el archivo que se quiere importar está guardado en una codificación distinta, algo frecuente en archivos antiguos, en archivos generados en ciertos sistemas o programas, o en archivos exportados con configuraciones que no usan la codificación universal. En esos casos, los caracteres básicos como las letras sin acentuar y los números suelen representarse igual y no dan problemas, pero los caracteres especiales, como las vocales con tilde, la eñe y otros símbolos propios de cada idioma, se representan de forma diferente según la codificación. Si la base de datos interpreta los bytes del archivo usando una codificación distinta de aquella con la que se guardó, esos caracteres especiales se traducen incorrectamente y aparecen como símbolos extraños, combinaciones raras de caracteres o signos sin sentido, lo que se conoce como caracteres corruptos. La solución a este problema tiene dos vertientes. La primera es asegurarse de que el archivo esté guardado en la codificación universal, para lo cual, si no lo está, se puede convertir usando un editor de texto o una herramienta que permita cambiar la codificación del archivo, guardándolo de nuevo en la codificación universal. La segunda es indicar explícitamente al comando de carga cuál es la codificación del archivo, de modo que la base de datos lo interprete correctamente, ya que muchos comandos de importación permiten especificar la codificación del archivo de origen. Comprobar y gestionar correctamente la codificación antes de importar es, por tanto, uno de los controles previos esenciales, junto con la verificación del separador, y evita el frustrante problema de acabar con una base de datos llena de textos con las tildes y las eñes corruptas, que además luego habría que corregir con un trabajo adicional.

El comando de carga de datos desde archivo de MySQL, conocido como LOAD DATA, y el comando de copia de PostgreSQL, conocido como COPY, son los comandos de carga masiva de cada uno de estos motores de base de datos, es decir, las instrucciones que permiten importar de forma eficiente un archivo completo de datos, como uno de valores separados por comas, insertándolo en una tabla de una sola vez en lugar de fila a fila. La característica esencial de estos comandos es que realizan una carga masiva, lo que significa que leen el archivo completo y lo insertan en la tabla mediante una operación optimizada, en contraste con la alternativa de generar y ejecutar una instrucción de inserción individual por cada fila del archivo. Esta diferencia es muy importante por motivos de rendimiento, ya que la carga masiva puede ser órdenes de magnitud más rápida que la inserción fila a fila, en la que cada inserción tiene su propio coste de procesamiento. Para un archivo con miles o millones de filas, la diferencia de tiempo entre una y otra técnica puede ser enorme, pasando de segundos a horas, por lo que para importar cantidades apreciables de datos siempre conviene usar el comando de carga masiva del motor correspondiente. En MySQL, este comando es el de carga de datos desde un archivo, que puede requerir ciertos permisos y configuraciones en el servidor para poder leer archivos. En PostgreSQL, el comando de copia tiene dos variantes importantes: la variante que se ejecuta en el servidor, que requiere que el propio servidor de la base de datos pueda acceder al archivo, lo que puede ser un inconveniente si el archivo está en el equipo del usuario y la base de datos en otro servidor; y una variante que se ejecuta desde el cliente de línea de comandos, que permite importar un archivo local del usuario sin necesitar permisos especiales en el servidor, siendo esta variante muy cómoda y práctica para importar datos desde el propio equipo. Al ejecutar cualquiera de estos comandos, hay que indicarles los parámetros que se han determinado en la preparación previa, como el separador real que utiliza el archivo, la codificación del archivo y si este tiene una primera fila de encabezados con los nombres de las columnas que hay que saltar para no intentar insertarla como si fuera un dato más. En resumen, estos comandos son la herramienta adecuada y eficiente para importar archivos de datos a las bases de datos, y conocer el de cada motor y sus opciones es esencial para realizar importaciones rápidas y correctas.

Los errores en los datos de un archivo de valores separados por comas se manejan anticipándolos, ya que los archivos del mundo real casi siempre presentan problemas, y las dos técnicas más útiles para ello son probar primero con una muestra pequeña del archivo y, en casos problemáticos, cargar los datos en una tabla intermedia de columnas de texto para limpiarlos antes de pasarlos a la tabla definitiva. El punto de partida es asumir que los datos del archivo tendrán defectos, porque en la práctica es lo habitual. Entre los problemas más frecuentes están las fechas con formatos que el motor no reconoce, los campos vacíos en columnas donde se espera un número, las filas con un número de columnas distinto del esperado, los textos que contienen comas o comillas dentro de un campo sin estar correctamente escapados, y la presencia de espacios o caracteres invisibles que ensucian los datos. Cualquiera de estos problemas puede hacer que la carga falle o que inserte datos incorrectos. La primera técnica para manejarlos es probar la importación con una muestra pequeña del archivo, por ejemplo con las primeras decenas de filas, antes de cargar el archivo completo. Esto permite detectar rápidamente los problemas sin tener que esperar a que se procese todo el archivo y sin arriesgarse a que la carga falle a mitad de un archivo enorme, de modo que se pueden identificar y corregir los defectos con agilidad. La segunda técnica, especialmente útil para archivos con muchos problemas, es la de la tabla intermedia, también llamada de preparación. En lugar de cargar los datos directamente en la tabla definitiva, que tiene tipos de datos estrictos como números y fechas que rechazarían los valores mal formados, se crea una tabla intermedia en la que todas las columnas son de tipo texto, ya que este tipo acepta prácticamente cualquier valor sin rechazarlo. Se cargan los datos del archivo en esa tabla intermedia, lo que casi siempre funciona sin problemas al no haber restricciones de tipo, y una vez dentro de la base de datos se limpian y validan los datos usando instrucciones de la propia base, corrigiendo los formatos de fecha, convirtiendo los textos a números, detectando y arreglando las filas problemáticas y depurando los datos. Solo cuando los datos ya están limpios se pasan, mediante una instrucción de la base de datos, a la tabla definitiva con sus tipos correctos. Esta técnica convierte el frágil planteamiento de que todo entre bien a la primera en un proceso robusto de cargar en bruto, limpiar y mover, que tolera los defectos del archivo y garantiza que los datos que acaban en la tabla final estén correctos y bien tipados.

Conviene importar el archivo de valores separados por comas a una base de datos cuando se quiere almacenar los datos de forma permanente e integrarlos con el resto del sistema, mientras que si el objetivo es simplemente analizar los datos del archivo de forma puntual, puede ser más ágil analizarlo directamente con una herramienta orientada al análisis, como una base de datos analítica que puede consultar archivos sin necesidad de importarlos previamente. La decisión depende, por tanto, del objetivo que se persiga con los datos del archivo. La importación a una base de datos tradicional como MySQL o PostgreSQL es la opción adecuada cuando los datos van a formar parte de un sistema de forma duradera, cuando se van a combinar y relacionar con otros datos ya existentes en la base, cuando van a ser consultados y modificados de forma continua por una aplicación, o cuando se necesita la integridad, la persistencia y las capacidades de gestión que ofrece una base de datos. En estos casos, importar el archivo mediante los comandos de carga masiva, con la debida preparación previa y el manejo de los errores de datos, es lo correcto, ya que integra los datos en la base para su uso continuado. Sin embargo, cuando el objetivo no es almacenar los datos sino analizarlos de forma puntual, por ejemplo para explorar un conjunto de datos, hacer unos cálculos, responder unas preguntas concretas o generar un informe, importar el archivo a una base de datos tradicional puede ser un rodeo innecesario, con todo el trabajo de preparación que conlleva. En esos casos resulta más ágil recurrir a una herramienta orientada al análisis de datos que sea capaz de consultar directamente los archivos, sin necesidad de crear una tabla ni de ejecutar un proceso de importación previo. Existen bases de datos analíticas diseñadas precisamente para este propósito, que permiten ejecutar consultas directamente sobre archivos de datos como los de valores separados por comas, de forma muy rápida y sin apenas configuración, lo que las hace idóneas para el análisis exploratorio y puntual de datos. La diferencia de enfoque es que la importación a una base de datos tradicional está orientada al almacenamiento y la gestión continuada de los datos, mientras que el análisis directo con una herramienta analítica está orientado a explorar y consultar los datos de forma rápida sin el compromiso de almacenarlos. Por ello, antes de emprender la importación de un archivo, conviene preguntarse si realmente se quieren almacenar y gestionar esos datos, en cuyo caso la importación es lo adecuado, o si solo se quieren analizar, en cuyo caso una herramienta de análisis directo puede ahorrar mucho trabajo y ofrecer un camino más ágil hacia el objetivo.