El problema de la tabla vacía
Las dos unidades anteriores dejaron una base de datos lista: tablas creadas, campos con su tipo, claves definidas, reglas de integridad en su lugar. Está perfecta. Y está vacía.
Una tabla bien diseñada y sin filas no responde ninguna pregunta. Sirve para guardar datos, no para tenerlos. En algún momento alguien tiene que cargarlos, y ahí aparece un problema que el diseño no resuelve solo.
La salida fácil es abrir el gestor y escribir fila por fila. Para probar alcanza. Para trabajar, no: quien atiende el mostrador de la biblioteca no va a abrir el gestor, no sabe SQL y —más importante— no debería tener permiso para tocar la estructura de las tablas. Un empleado que puede escribir en la tabla de socios es un empleado que puede borrarla.
Entonces los datos tienen que entrar por otro lado: por una pantalla hecha a medida, que pida exactamente lo que hace falta y no permita nada más. Y esa pantalla, salvo excepciones, vive en el navegador.
Esta unidad trata de ese camino completo: de la pantalla a la tabla.
Las tres piezas
Cargar un dato por la web parece una sola acción —el usuario llena un casillero y aprieta un botón— pero por dentro son tres cosas distintas, y conviene verlas separadas porque cada una se estudia aparte:
| Pieza | Qué resuelve | Con qué se hace |
|---|---|---|
| La interfaz | Que el usuario vea dónde escribir y entienda qué le están pidiendo. | Páginas web: HTML para el contenido y CSS para la presentación. |
| El formulario | Qué datos se piden, de qué tipo y con qué controles. | <input>, <select>, <textarea> y sus validaciones. |
| El envío y la escritura | Hacer viajar los datos hasta el servidor y guardarlos en la tabla. | Los métodos GET y POST, y la sentencia INSERT de SQL. |
Lo importante es que las tres dependen de la anterior. Un formulario mal armado pierde datos antes de que salgan de la computadora del usuario, y de nada sirve tener la mejor sentencia INSERT del mundo si el campo nunca llegó al servidor. Casi todos los datos mal cargados que se encuentran en una base de datos real no vienen de un error de SQL: vienen de una pantalla que permitió escribir cualquier cosa.
Temas de la unidad
Los temas van en el orden del programa: primero qué es una interfaz web y cómo se pide un dato, después cómo se construye esa pantalla, y al final cómo llega el dato a la tabla.
| Tema del programa | Qué se ve |
|---|---|
| Interfaces web | Qué es una interfaz, por qué el navegador reemplazó a los programas instalados, y el reparto de tareas entre el cliente y el servidor. |
| Formularios web | La herramienta concreta para pedir datos: la etiqueta <form>, la anatomía de un campo y el atributo que decide los nombres con los que los datos llegan. |
| HTML y CSS |
HTML: la estructura y el significado, con sus once contenidos (estructura básica, textos, listas, enlaces, imágenes, semántica, tablas, formularios y validaciones). CSS: la presentación, también con once contenidos (selectores, cascada, colores, tipografía, modelo de caja, unidades, flexbox, diseño adaptable y estados). |
| Bootstrap | Cómo se inserta una hoja de estilos ya escrita y cómo se usa: la rejilla de 12 columnas, los componentes, las clases de utilidad y cuándo conviene apoyarse en un framework. |
Tipos de ingreso (input, select) |
Qué control le corresponde a cada dato, y por qué elegir mal el control es la causa más común de datos sucios. |
Métodos de envío: GET y POST |
Los dos caminos que tienen los datos para viajar al servidor, en qué se diferencian y cuándo corresponde cada uno. |
| Inserción de datos en la base | El recorrido completo del dato: qué hace el servidor cuando llega el formulario y qué puede fallar en el camino. |
Esta unidad usa el SQL todo el tiempo —para insertar el dato y para comprobarlo—, pero no lo enseña: el lenguaje se estudia en la Unidad 3 · Introducción a SQL.
Y retoma lo que ya se vio en la Unidad 1 —los tipos de datos y las reglas de integridad, que son los que van a rechazar el dato mal cargado— y prepara el terreno para la Unidad 4, donde el mismo camino se recorre también al revés: mostrar, modificar y borrar lo que está guardado.
Resumen
- Una base de datos diseñada y vacía no sirve: los datos tienen que entrar de alguna manera.
- Cargarlos desde el gestor sirve para probar, pero no para trabajar ni para dar acceso a otras personas.
- La carga se hace por una pantalla web, que pide exactamente los datos necesarios.
- El camino tiene tres piezas: la interfaz, el formulario y el envío con la escritura en la tabla.
- Las tres dependen de la anterior: el eslabón más débil arruina el resultado de todo el circuito.
- Los datos sucios de una base real casi nunca vienen del SQL, sino de un formulario que aceptó cualquier cosa.