Carga de datos

La sentencia INSERT INTO

Con la tabla creada, el paso siguiente es cargarle datos. La instrucción que agrega un registro se llama INSERT INTO y tiene dos formas de escribirse:

-- 1. Nombrando los campos (la forma recomendada)
INSERT INTO socios (nombre, documento, correo, alta)
VALUES ('Ana Pérez', '30123456', '[email protected]', '2026-05-12');

-- 2. Sin nombrarlos: hay que dar TODOS los campos, en el orden exacto de la tabla
INSERT INTO socios
VALUES (NULL, 'Ana Pérez', '30123456', '[email protected]', '2026-05-12', 1);

Las dos funcionan, y la primera es mejor por tres razones que conviene entender:

• Se lee sin tener que mirar la tabla. En la primera sentencia se ve de un vistazo qué valor corresponde a qué campo. En la segunda, el cuarto valor es un misterio hasta abrir la estructura de la tabla.
• Se puede omitir lo que no se carga. Al nombrar los campos, los que no aparecen toman su valor por defecto o quedan vacíos. Sin la lista, hay que dar todos, incluso los que no se conocen —y ahí es donde aparecen los NULL y los ceros de relleno que después arruinan los promedios—.
• No se rompe si la tabla cambia. El día que se agregue un campo nuevo, la primera sentencia sigue funcionando igual; la segunda empieza a guardar los valores en el lugar equivocado, sin dar ningún error.

En la primera forma se ve un NULL en el id de la segunda. Y ahí aparece una regla: si el campo del identificador es AUTO_INCREMENT, no se pone. Se lo omite de la lista de campos y la base le asigna el número siguiente sola. Si se lo incluye, hay que pasarle algo —de ahí el NULL— y es una complicación innecesaria.

Un detalle de dialecto que aparece mucho en phpMyAdmin y confunde: MySQL acepta una tercera forma, INSERT INTO socios SET nombre = 'Ana Pérez', documento = '30123456'. Es cómoda porque cada valor va pegado al nombre de su campo, pero no es SQL estándar: no funciona en SQLite ni en otros gestores. Conviene reconocerla —hay herramientas que la generan— y escribir siempre las formas estándar.

Inserción de uno o varios registros

Cuando hay que cargar muchos datos, no hace falta una sentencia por registro. Se pueden encadenar varios grupos de valores en un solo INSERT:

INSERT INTO libros (titulo, autor)
VALUES
    ('Cien años de soledad', 'Gabriel García Márquez'),
    ('Rayuela', 'Julio Cortázar'),
    ('El aleph', 'Jorge Luis Borges'),
    ('La invención de Morel', 'Adolfo Bioy Casares');

La diferencia no es solo de comodidad: es bastante más rápido que cuatro sentencias separadas, porque la base resuelve todo el trabajo en una sola operación en lugar de cuatro. Es lo que se usa para cargar una tabla de referencia —provincias, categorías, planes— de una vez.

Y tiene una propiedad que conviene conocer: las filas del mismo INSERT se tratan como una sola operación, así que si una de ellas falla, la sentencia completa se rechaza y no se inserta ninguna. Eso es una ventaja, no un problema: deja la tabla en un estado consistente, en lugar de cargada a medias. Si en cambio se hicieran cuatro INSERT separados y el tercero fallara, las tres primeras filas ya estarían guardadas y habría que averiguar cuáles entraron.

La correspondencia entre valores y tipos

Escribir un INSERT es, en el fondo, ubicar cada valor en su lugar. Y para eso hay dos cosas que tienen que coincidir: el orden y la forma de escribir el valor.

El orden es lo único que conecta la lista de campos con la lista de valores: van uno a uno, de izquierda a derecha. Si se cambia el orden de los campos y no el de los valores, la base no se queja: escribe el correo en el campo del nombre y sigue. El dato queda mal guardado sin ningún error, y eso es peor que un error.

La forma depende del tipo, y equivocarse es la causa de la mitad de los errores de sintaxis:

Las comillas de SQL son simples, no dobles. Poner comillas dobles es un error que confunde mucho, porque en el gestor a veces funciona —depende de la configuración y del gestor— y en otros contextos no. Con las comillas simples no hay ambigüedad posible.

Y hay dos trampas que valen la pena tener presentes desde el primer día, porque son locales:

• Los decimales se escriben con punto, no con coma. En castellano escribimos 12,50; en SQL hay que escribir 12.50. El 12,50 no es un número con decimales: SQL lo lee como dos valores separados por una coma, y la sentencia falla con un error de sintaxis que no dice nada de esto.
• Las fechas van en formato AAAA-MM-DD. Es el único de los formatos posibles que no se puede confundir: '2026-05-12' es el 12 de mayo de 2026 y no hay manera de leerlo al revés. Por eso se eligió ese orden —va de lo más grande a lo más chico— y por eso conviene no usar '12/05/2026' aunque el gestor lo acepte.

Qué pasa si el valor no corresponde

La base de datos hace cumplir los tipos y las restricciones, y cuando algo no encaja puede reaccionar de tres maneras distintas: rechazar el registro con un error, convertir el valor a lo que se pueda, o recortarlo. Cuál de las tres ocurra depende del gestor, de su versión y de su configuración.

Archivos para practicar

Todo lo que se explica en esta página se puede probar de verdad, sin copiar y pegar sentencia por sentencia. Cada archivo crea su propia base, con las tablas y los datos ya cargados, y trae al final —comentadas— las consultas para practicar.

Cómo se importa

Importar es abrir el archivo .sql dentro del gestor para que él ejecute todas las sentencias de una sola vez. Son cuatro pasos, y son siempre los mismos:

1. Descargar el archivo desde la tabla de arriba y fijarse dónde quedó: casi siempre, en la carpeta Descargas.
2. Abrir phpMyAdmin —en XAMPP, el botón Admin que está en la fila de MySQL— y entrar a la pestaña Importar, la que está arriba de todo.
3. Elegir el archivo con el botón Seleccionar archivo. No hace falta crear antes la base de datos: el archivo la crea.
4. Apretar Importar y esperar el mensaje verde: «La importación se ha finalizado correctamente».

Si el mensaje es verde, ya está: la base aparece en la lista de la izquierda, con sus tablas y con los datos cargados. Si sale en rojo, phpMyAdmin dice en qué línea del archivo se trabó, y las dos causas más comunes son que la base ya existía o que el archivo se cortó al descargarse.

Cuidado con el nombre de la base. Al importar, cada archivo borra la base con ese nombre si ya existía y la vuelve a crear vacía. Es lo que permite repetir la práctica todas las veces que haga falta —siempre arranca igual—, pero también significa que no conviene guardar datos propios en una base que se llame biblioteca_1_tabla, biblioteca_2_tablas o biblioteca_3_tablas.

Resumen

• INSERT INTO tabla (campos) VALUES (valores) agrega un registro.
• Siempre conviene nombrar los campos: se lee mejor, se pueden omitir los que no se cargan y no se rompe si la tabla cambia.
• El campo AUTO_INCREMENT no se pone: lo asigna la base.
• Se pueden cargar varios registros en una sola sentencia, y es bastante más rápido.
• Las filas del mismo INSERT se aplican todas o ninguna.
• El orden de los valores sigue al de los campos: si no coinciden, el dato se guarda mal sin error.
• Texto y fechas entre comillas simples; números sin comillas; NULL sin comillas.
• NULL y '' son cosas distintas.
• Los decimales van con punto, no con coma, y las fechas en formato AAAA-MM-DD.
• La base puede rechazar, convertir o recortar. Las conversiones y los recortes son silenciosos: hay que escribir bien el dato, no esperar que la base lo arregle.

Ver las consultas básicas