Inserción de datos

El recorrido completo

Todo lo que se vio hasta acá desemboca en este momento: el dato escrito en un casillero se convierte en una fila de una tabla. El camino tiene cuatro estaciones, y conviene verlas juntas porque ahí se entiende dónde puede romperse la cadena.

Vale fijarse en una cosa del dibujo: el servidor es el único que decide. El formulario ayuda, pero el que revisa de verdad, el que arma la orden y el que recibe la respuesta de la base de datos es él. Por eso todo lo que se valida en el navegador tiene que volver a validarse en el servidor: es el único punto del camino que el usuario no controla.

Qué hace el servidor

Cuando la petición llega, el programa del servidor hace siempre los mismos pasos, en el mismo orden:

El paso 6 es el que menos se cuida y el que más problemas causa. Un formulario que se limpia solo después de guardar, sin decir nada, deja al usuario con la duda de si funcionó. Y la consecuencia típica es que lo carga de nuevo: si la clave no lo impide, quedan dos socios con el mismo nombre.

La sentencia INSERT

Todo el recorrido termina en una instrucción de SQL. Es la que efectivamente crea la fila:

INSERT INTO socios (nombre, correo, nacimiento)
VALUES ('Ana Pérez', '[email protected]', '1998-04-12');

Se lee casi como una frase, y tiene tres partes:

• INSERT INTO socios: en qué tabla se va a insertar.
• (nombre, correo, nacimiento): qué campos se van a llenar.
• VALUES (...): con qué valores, en el mismo orden que los campos.

El orden es lo único que conecta las dos listas. Si se cambia el orden de los campos y no el de los valores, la base de datos no se queja: escribe el correo en la columna del nombre y sigue. El dato queda mal guardado sin ningún error, y eso es peor que un error.

Dos cosas que no hacen falta escribir. El campo del identificador, si está configurado como autonumérico, no se pone: el gestor lo asigna solo. Y los campos que no se nombran quedan con su valor por defecto o en NULL, según cómo se haya definido la tabla. Esa es una decisión que se tomó en el diseño, no acá.

Comillas, números y NULL

Cómo se escribe cada valor depende de su 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 muchísimo, porque en el gestor a veces funciona —depende de la configuración— y desde el servidor no. Y hay una distinción que hay que tener clara: NULL no es una cadena vacía ni un cero.

• NULL significa «no hay dato»: no se sabe, no se preguntó, no corresponde.
• '' —la cadena vacía— significa «el dato existe y está vacío».
• 0 significa «el valor es cero».

Son tres cosas distintas y se usan para cosas distintas. Un campo teléfono con NULL quiere decir que no se cargó; con '', que se declaró que no tiene. Confundirlos trae problemas al contar y al promediar: NULL no cuenta en los promedios y el cero sí, así que un promedio calculado sobre datos con ceros de relleno da mal y nadie entiende por qué.

Insertar varias filas de una vez

Cuando hay que cargar muchos datos, no hace falta una sentencia por fila. Se pueden encadenar varios grupos de valores:

INSERT INTO provincias (codigo, nombre)
VALUES
    ('ba', 'Buenos Aires'),
    ('cba', 'Córdoba'),
    ('sf', 'Santa Fe');

Es bastante más rápido que tres sentencias separadas, porque la base de datos resuelve todo el trabajo en una sola operación. Es lo que se usa para cargar una tabla de referencia —provincias, categorías, planes— de una sola vez. Y tiene una propiedad que conviene conocer: si una de las filas falla, según cómo esté configurada la operación puede no insertarse ninguna. Eso es una ventaja, no un problema: deja la tabla en un estado consistente en lugar de cargada a medias.

Seguridad de las consultas

Cuando un formulario envía valores que se usan en una consulta, hay que evitar que esos datos puedan cambiar la instrucción SQL. La explicación de la inyección SQL y las consultas preparadas está reunida en la Unidad 3.

Qué puede fallar

Aun con el formulario bien hecho y la sentencia bien armada, la base de datos puede rechazar la inserción. Y está bien que lo haga: es su trabajo. Las razones más comunes:

Todas esas reglas se definieron en la Unidad 1, al diseñar las tablas, y son exactamente las que ahora están trabajando. Es el momento en que el diseño deja de ser teoría: los tipos, las claves y las restricciones son la última línea de defensa de la calidad del dato. Aunque el formulario esté mal, aunque el servidor no valide nada, aunque alguien escriba la sentencia a mano, la base no va a guardar un dato que viole sus reglas.

Dicho eso, hay que evitar una conclusión equivocada: que la base rechace el dato no es un buen manejo del error. Significa que el error llegó demasiado lejos. Cuando eso pasa, el usuario tiene que ver un mensaje claro que le diga qué corregir, no una página de error del servidor. Y si se trata de una clave duplicada, el mensaje tiene que decir «ya existe un socio con ese documento» —eso lo entiende cualquiera— y no «Duplicate entry '30123456' for key 'socios.documento'», que es lo que dice la base de datos y no le sirve a nadie.

Comprobar que quedó guardado

Después de insertar, conviene verificar en lugar de confiar. La comprobación es una consulta de lectura, y es la primera que se ve del lenguaje SQL:

SELECT * FROM socios WHERE documento = '30123456';

Se pide a la tabla socios que devuelva todas las columnas de las filas cuyo documento sea ese. Si aparece una fila con los datos correctos, la inserción funcionó. Y si en lugar de una aparecen dos, se descubrió un problema que de otro modo no se habría notado hasta mucho después: el formulario se envió dos veces y quedaron dos socios. Ese es el tipo de dato sucio que después cuesta limpiar, porque hay que decidir cuál de los dos es el bueno. La consulta SELECT, con sus condiciones y sus filtros, es el tema de la página siguiente.

Resumen

• El recorrido tiene cuatro estaciones: formulario, petición, servidor y tabla.
• El servidor es el único que decide: revisa de nuevo, arma la orden y recibe la respuesta.
• Los pasos son recibir, validar, conectar, armar, ejecutar y responder.
• Responder bien es parte del trabajo: un formulario que se vacía en silencio hace que el usuario cargue el dato dos veces.
• INSERT INTO tabla (campos) VALUES (valores) crea la fila, con los valores en el mismo orden que los campos.
• El texto y las fechas van entre comillas simples; los números, sin comillas; NULL, sin comillas.
• NULL, la cadena vacía y el cero son tres cosas distintas.
• Se pueden insertar varias filas de una vez, y es mucho más rápido.
• Para proteger las consultas que usan valores del formulario, ver Inyección SQL y consultas preparadas.
• La base de datos puede rechazar la inserción: tipos, campos obligatorios, claves únicas y foráneas, largos y fechas. Es la última línea de defensa.
• Un rechazo necesita un mensaje claro para el usuario, no el texto del error del gestor.
• Conviene comprobar con SELECT en lugar de confiar.

Seguir con la Unidad 4 · Proyectos