PHP con MySQL: PDO, CRUD y consultas seguras paso a paso

Aprende SQL además de aprender PHP

Un error habitual es aprender únicamente cómo ejecutar consultas desde PHP.

Eso puede funcionar mientras los ejemplos sean sencillos, pero limita rápidamente tu capacidad para diseñar sistemas.

SELECT

Recupera información.

INSERT

Crea nuevos registros.

UPDATE

Modifica información existente.

DELETE

Elimina registros.

JOIN

Permite combinar información relacionada de varias tablas.

PHP ejecuta estas consultas, pero SQL sigue siendo un lenguaje que necesitas comprender por separado.

Empecemos con una tabla de usuarios

CREATE TABLE usuarios (
    id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    nombre VARCHAR(120) NOT NULL,
    email VARCHAR(190) NOT NULL UNIQUE,
    password_hash VARCHAR(255) NOT NULL,
    activo TINYINT(1) NOT NULL DEFAULT 1,
    creado_en DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP
);

id identifica cada registro

Una clave primaria proporciona una referencia única para cada usuario.

email tiene una restricción UNIQUE

Eso ayuda a impedir que se almacenen dos usuarios con el mismo email.

No guardamos la contraseña como texto

Guardamos un hash producido desde PHP mediante funciones diseñadas específicamente para contraseñas.

La aplicación debe manejar errores sin revelar información sensible

Durante desarrollo, un error detallado puede ayudarte a encontrar el problema.

En producción, mostrar credenciales, rutas internas o consultas completas puede ser peligroso.

<?php

try {

    $pdo = new PDO(
        $dsn,
        $usuarioDb,
        $passwordDb,
        [
            PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION
        ]
    );

} catch (PDOException $e) {

    error_log($e->getMessage());

    exit(
        'No fue posible conectar con la base de datos.'
    );
}

El usuario recibe un mensaje controlado, mientras el detalle técnico puede registrarse internamente.

INSERT: guardar un registro utilizando una consulta preparada

<?php

$sql = "
    INSERT INTO usuarios (
        nombre,
        email,
        password_hash
    )
    VALUES (
        :nombre,
        :email,
        :password_hash
    )
";

$stmt = $pdo->prepare($sql);

$stmt->execute([
    'nombre' => $nombre,
    'email' => $email,
    'password_hash' => $passwordHash,
]);

Los parámetros van separados de la consulta

Los valores no se concatenan directamente dentro del SQL.

La contraseña debe convertirse primero en hash

<?php

$passwordHash = password_hash(
    $password,
    PASSWORD_DEFAULT
);

Nunca necesitas recuperar la contraseña original desde la base de datos.

Buscar un usuario por email

<?php

$sql = "
    SELECT
        id,
        nombre,
        email,
        password_hash,
        activo
    FROM usuarios
    WHERE email = :email
    LIMIT 1
";

$stmt = $pdo->prepare($sql);

$stmt->execute([
    'email' => $email
]);

$usuario = $stmt->fetch();

Este patrón aparece constantemente en login, perfiles, búsquedas y comprobaciones de existencia.

DELETE: eliminar información de manera controlada

<?php

$sql = "
    DELETE FROM usuarios
    WHERE id = :id
";

$stmt = $pdo->prepare($sql);

$stmt->execute([
    'id' => $id
]);

Técnicamente es sencillo; conceptualmente puede no serlo

En una aplicación real debes decidir qué ocurre con información relacionada.

Por ejemplo: ¿qué ocurre con pedidos, comentarios, archivos o auditorías asociados al usuario?

La estructura de la base de datos importa tanto como la consulta PHP.

No construyas SQL concatenando directamente datos del usuario

Este tipo de código debería evitarse:

<?php

$sql = "
    SELECT *
    FROM usuarios
    WHERE email = '" . $_POST['email'] . "'
";

La información recibida está entrando directamente en la estructura de la consulta.

Utiliza parámetros

<?php

$sql = "
    SELECT *
    FROM usuarios
    WHERE email = :email
";

$stmt = $pdo->prepare($sql);

$stmt->execute([
    'email' => $email
]);

Las aplicaciones reales suelen tener varias tablas relacionadas

Imagina un ecommerce.

Un usuario puede tener muchos pedidos.

Un pedido puede contener varios productos.

Los productos pueden pertenecer a categorías.

Claves foráneas

CREATE TABLE pedidos (
    id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    usuario_id BIGINT UNSIGNED NOT NULL,
    total DECIMAL(12,2) NOT NULL,
    estado VARCHAR(50) NOT NULL,
    creado_en DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,

    CONSTRAINT fk_pedidos_usuario
        FOREIGN KEY (usuario_id)
        REFERENCES usuarios(id)
);

Ahora cada pedido puede relacionarse con un usuario mediante usuario_id.

Algunas operaciones deben completarse juntas o no completarse

Imagina una compra.

Necesitas crear un pedido, guardar sus productos y quizás descontar stock.

Si una operación falla en medio, no quieres dejar la base en un estado incoherente.

<?php

try {

    $pdo->beginTransaction();

    // 1. Crear pedido.
    // 2. Insertar productos del pedido.
    // 3. Actualizar stock.

    $pdo->commit();

} catch (Throwable $e) {

    if ($pdo->inTransaction()) {
        $pdo->rollBack();
    }

    throw $e;
}

commit confirma

Los cambios se guardan como una unidad.

rollBack revierte

Si algo falla, puedes deshacer los cambios realizados dentro de la transacción.

Los índices pueden acelerar búsquedas, pero no deberían añadirse al azar

Si constantemente buscas usuarios por email, tener ese campo correctamente indexado puede mejorar las consultas.

PRIMARY KEY ya crea una estructura útil para id

Las claves principales suelen utilizarse constantemente para localizar registros.

UNIQUE también puede servir como índice

En nuestro ejemplo, email necesita ser único.

Más índices no significa automáticamente más velocidad

También tienen coste de almacenamiento y mantenimiento durante escrituras.

Debes diseñarlos según consultas reales.

No distribuyas consultas SQL por cada archivo HTML de la aplicación

En un CRUD de aprendizaje puede parecer cómodo escribir consultas directamente donde muestras la interfaz.

Cuando el proyecto crece, esa organización se vuelve difícil de mantener.

Separa acceso a datos

Centraliza las operaciones relacionadas con persistencia.

Separa reglas de negocio

Determinar si un usuario puede cancelar un pedido es una regla, no una consulta SQL.

Separa presentación

Generar HTML debería ser una responsabilidad distinta de actualizar una base de datos.

Construye un CRUD completo para aprender PHP con MySQL

Comprender SQL y bases de datos también mejora tu nivel como desarrollador WordPress

WordPress almacena gran parte de su información en una base de datos relacional.

Sin embargo, cuando desarrollas dentro de WordPress, no deberías saltar automáticamente a consultas SQL personalizadas.

Utiliza primero las APIs disponibles

Posts, usuarios, metadata y opciones disponen de funciones específicas.

Usa $wpdb cuando realmente necesitas acceso SQL

En ese contexto, conceptos como parámetros, índices, relaciones y rendimiento siguen siendo muy importantes.

Qué evitar al trabajar con PHP y MySQL

Aprender PHP con MySQL significa aprender a diseñar datos, no solo ejecutar consultas