ORM

El problema sin ORM

Una aplicación necesita buscar un producto por su ID.

Lo que se repite siempre

• Abrir y cerrar la conexión.
• Escribir SQL para cada operación: SELECT, INSERT, UPDATE, DELETE.
• Mapear manualmente cada columna a un campo del diccionario u objeto.
• Gestionar errores y transacciones de forma manual.
• Sincronizar el esquema SQL con la estructura de datos en el código.

Con 10 tablas, el código de acceso a datos se vuelve masivo.

La mezcla de responsabilidades

# ¿Esto es lógica de negocio o SQL?
def aprobar_pedido(pedido_id):
    cursor.execute(
        "UPDATE pedidos SET estado = 'aprobado', "
        "fecha_aprobacion = NOW() WHERE id = %s",
        (pedido_id,)
    )
    cursor.execute(
        "UPDATE inventario SET reservado = reservado - cantidad "
        "FROM pedido_detalle WHERE pedido_id = %s",
        (pedido_id,)
    )
    conn.commit()
            

Definición

Object Relational Mapping — Mapeo Objeto-Relacional.

Una capa de abstracción que traduce entre dos mundos.

Los dos mundos

La idea central

En lugar de escribir SQL, se trabaja con objetos del lenguaje de programación. El ORM traduce automáticamente.

cursor.execute(
    "SELECT * FROM productos WHERE precio < %s",
    (100,)
)
                

productos = Producto.query.filter(
    Producto.precio < 100
).all()
                

Mismo resultado, distinta abstracción.

El mapeo en la práctica

Se define la tabla como una clase:

class Producto(Base):
    __tablename__ = "productos"

    id      = Column(Integer, primary_key=True)
    nombre  = Column(String(200), nullable=False)
    precio  = Column(Numeric(10, 2), nullable=False)
    stock   = Column(Integer, default=0)
        

A partir de esa definición, el ORM sabe cómo construir el SQL necesario.

ORMs más usados

Tabla comparativa — Python y PHP

Tabla comparativa — Java y TypeScript

SQLAlchemy con PostgreSQL y MySQL

Configuración de conexión

from sqlalchemy import create_engine

# PostgreSQL
engine = create_engine("postgresql+psycopg2://usuario:clave@localhost/tienda")

# MySQL
engine = create_engine("mysql+pymysql://usuario:clave@localhost/tienda")
        

Solo cambia la cadena de conexión — el código ORM es idéntico para ambos motores.

Definir modelos con relación

from sqlalchemy import Column, Integer, String, Numeric, ForeignKey
from sqlalchemy.orm import DeclarativeBase, relationship

class Base(DeclarativeBase):
    pass

class Categoria(Base):
    __tablename__ = "categorias"
    id     = Column(Integer, primary_key=True)
    nombre = Column(String(100), nullable=False, unique=True)
    productos = relationship("Producto", back_populates="categoria")

class Producto(Base):
    __tablename__ = "productos"
    id           = Column(Integer, primary_key=True)
    nombre       = Column(String(200), nullable=False)
    precio       = Column(Numeric(10, 2), nullable=False)
    stock        = Column(Integer, default=0)
    categoria_id = Column(Integer, ForeignKey("categorias.id"))
    categoria    = relationship("Categoria", back_populates="productos")
        

Consultar registros

with Session(engine) as session:

    # Todos los productos
    todos = session.query(Producto).all()

    # Por ID
    uno = session.get(Producto, 5)

    # Con filtros y orden
    disponibles = session.query(Producto).filter(
        Producto.stock > 0,
        Producto.precio < 2000
    ).order_by(Producto.precio).all()
        

Relaciones: sin escribir JOINs

with Session(engine) as session:
    producto = session.get(Producto, 5)

    # Sin escribir un JOIN
    print(producto.nombre)
    print(producto.categoria.nombre)
            

SELECT categorias.id, categorias.nombre
FROM categorias
WHERE categorias.id = 1
                

Eloquent con MySQL y PostgreSQL

Definir un modelo

namespace App\Models;

use Illuminate\Database\Eloquent\Model;

class Producto extends Model
{
    protected $table = 'productos';

    protected $fillable = [
        'nombre', 'precio', 'stock', 'categoria_id',
    ];

    public function categoria()
    {
        return $this->belongsTo(Categoria::class);
    }
}
        

Operaciones CRUD

// Insertar
$producto = Producto::create([
    'nombre'       => 'Laptop',
    'precio'       => 5000.00,
    'stock'        => 10,
    'categoria_id' => 1,
]);

// Buscar por ID
$producto = Producto::find(5);

// Con filtros
$baratos = Producto::where('precio', '<', 1000)
                   ->where('stock', '>', 0)
                   ->orderBy('precio')
                   ->get();

// Actualizar y eliminar
$producto->precio = 4500.00;
$producto->save();
$producto->delete();
        

Acceso a relaciones y cambio de motor

$producto = Producto::find(5);

echo $producto->nombre;
// JOIN automático:
echo $producto->categoria->nombre;
                

# MySQL
DB_CONNECTION=mysql
DB_PORT=3306

# PostgreSQL
DB_CONNECTION=pgsql
DB_PORT=5432
                

ORM y SQL Injection

El problema central

Construir SQL con concatenación de strings es la causa raíz de SQL Injection.

# Vulnerable — datos del usuario directamente en el SQL
query = f"SELECT * FROM usuarios WHERE email = '{email}'"
        

Demostración: input malicioso

nombre_buscado = "'; DROP TABLE productos; --"

# Sin ORM — vulnerable
query = f"SELECT * FROM productos WHERE nombre = '{nombre_buscado}'"
# Ejecuta: SELECT * FROM productos WHERE nombre = ''; DROP TABLE productos; --'

# Con ORM — seguro
session.query(Producto).filter(Producto.nombre == nombre_buscado).all()
# Genera: SELECT * FROM productos WHERE nombre = $1
# Parámetro: "'; DROP TABLE productos; --"  (texto, no SQL)
        

La tabla no se elimina. El input malicioso es buscado literalmente como nombre.

Protección en todas las operaciones

# Todo parametrizado automáticamente
session.add(Producto(nombre=nombre, precio=precio))   # INSERT parametrizado
session.query(Producto).filter(Producto.id == id)     # SELECT parametrizado
producto.precio = nuevo_precio; session.commit()       # UPDATE parametrizado
session.delete(producto)                               # DELETE por PK
        

El desarrollador no necesita recordar parametrizar — el ORM lo hace por defecto.

La excepción: raw queries

Cuando se escribe SQL crudo, puede reaparecer la vulnerabilidad.

session.execute(
    text(f"SELECT * FROM productos "
         f"WHERE nombre = '{nombre}'")
)
                

session.execute(
    text("SELECT * FROM productos "
         "WHERE nombre = :nombre"),
    {"nombre": nombre}
)
                

DB::select(
  "SELECT * FROM productos
   WHERE nombre = '$nombre'"
);
                

DB::select(
  "SELECT * FROM productos
   WHERE nombre = ?",
  [$nombre]
);
                

Usos

Resumen: con ORM vs sin ORM

Limitaciones del ORM

El ORM no es una solución perfecta para todo.

El problema N+1

productos = session.query(Producto).all()   # query 1: trae todos los productos

for producto in productos:
    print(producto.categoria.nombre)        # query 2, 3, 4 ... N+1
        

Parece inocente. Pero el ORM hace una query extra por cada producto al acceder a .categoria.

Lo que realmente pasa en la base de datos

-- Query 1: traer los productos
SELECT * FROM productos;                          -- devuelve 1000 filas

-- Query 2: categoría del producto 1
SELECT * FROM categorias WHERE id = 3;
-- Query 3: categoría del producto 2
SELECT * FROM categorias WHERE id = 1;
-- Query 4: categoría del producto 3
SELECT * FROM categorias WHERE id = 3;
-- ...
-- Query 1001: categoría del producto 1000
SELECT * FROM categorias WHERE id = 7;
        

1000 productos = 1001 queries. El ORM las dispara en silencio.

Eager loading: traer todo en una sola query

from sqlalchemy.orm import joinedload

productos = session.query(Producto).options(
    joinedload(Producto.categoria)
).all()

# Ahora esto NO hace queries extra
for producto in productos:
    print(producto.categoria.nombre)
            

SELECT productos.*, categorias.*
FROM productos
LEFT OUTER JOIN categorias
  ON categorias.id = productos.categoria_id
                

Lazy vs Eager loading

Lazy loading es cómodo para un objeto. Eager loading es obligatorio para listas.

Abstracción que oculta lo que sucede

# ¿Cuántas queries ejecuta esto?
for pedido in session.query(Pedido).all():
    total = sum(d.cantidad * d.precio for d in pedido.detalles)
        

Otras limitaciones

ORM y base de datos en producción

El ORM no reemplaza el conocimiento de SQL.

Ver el SQL que genera el ORM

Indispensable para depurar problemas de rendimiento.

print(
    session.query(Producto)
    .filter(Producto.precio < 1000)
)
                

print(
    Producto.objects
    .filter(precio__lt=1000)
    .query
)
                

Un ORM mal usado es más lento que SQL directo.

Índices: no son automáticos

El ORM solo crea índice en la clave primaria. Los demás deben definirse explícitamente.

class Producto(Base):
    __tablename__ = "productos"

    id     = Column(Integer, primary_key=True)
    nombre = Column(String(200), index=True)   # crea índice en nombre
    precio = Column(Numeric(10, 2), nullable=False)
        

Sin los índices correctos, las consultas del ORM serán lentas igual que el SQL directo.

La combinación es válida

ORM para las operaciones del día a día, SQL directo para lo que el ORM no maneja bien.

# Llamar a un procedimiento almacenado desde el ORM
session.execute(text("CALL procesar_inventario_diario()"))
        

Las reglas de negocio complejas pueden seguir viviendo en procedimientos almacenados.