EVITAR

Por ejemplo, si el requisito consiste en obtener las direcciones postales de los clientes, esta consulta devuelve toda la información almacenada en la tabla.

SELECT *
FROM Customers;

El resultado podría incluir teléfonos, observaciones, fechas de actividad, atributos comerciales o campos sensibles que no forman parte del caso de uso.

BUENA PRÁCTICA

Es preferible seleccionar expresamente los campos necesarios:

SELECT 
    CustomerID,
    FirstName,
    LastName,
    Address,
    City,
    State,
    PostalCode,
    Country
FROM Customers;

Esta práctica mejora la legibilidad, limita el volumen de datos procesado y reduce el riesgo de incorporar información innecesaria. También mantiene estable el contrato de la consulta: si la tabla de origen añade nuevas columnas, estas no se incluirán automáticamente en el modelo o en el resultado.

EVITAR

Caso 1. Ocultar la multiplicación causada por un JOIN: Una relación uno a muchos (1-M) puede generar varias filas por cada registro de la tabla principal.

SELECT DISTINCT
    c.CustomerID,
    c.FirstName,
    c.LastName
FROM Customers c
INNER JOIN Orders o
    ON c.CustomerID = o.CustomerID;

En este caso DISTINCT elimina las repeticiones, pero oculta que la multiplicación de filas procede de la relación entre clientes y pedidos. Antes de eliminar esas filas, debe determinarse si el objetivo consiste en comprobar la existencia de pedidos o en calcular información agregada sobre ellos.

Por tanto, no debe evitarse DISTINCT por ser incorrecto, sino su uso automático para compensar una multiplicación de filas cuyo origen y propósito no se han analizado.

Caso 2. Intentar corregir una granularidad mal definida: DISTINCT determina la unicidad a partir de la combinación completa de las columnas seleccionadas:

SELECT DISTINCT
    FirstName, 
    LastName, 
    Address 
FROM Customers;

Dos clientes diferentes podrían compartir nombre, apellido y dirección. En ese caso, la consulta los presentaría como una sola fila, aunque sean entidades distintas. También debe evitarse utilizar GROUP BY con todas las columnas únicamente para eliminar registros repetidos:

SELECT
    CustomerID,
    FirstName,
    LastName,
    Address
FROM Customers
GROUP BY
    CustomerID,
    FirstName,
    LastName,
    Address;

Si no existe ninguna agregación, GROUP BY actúa únicamente como sustituto de DISTINCT y no permite comprender ni corregir el origen de las duplicidades.

BUENA PRÁCTICA

Caso 1. Define correctamente la granularidad: si el resultado debe representar clientes individuales, incluye la clave que identifica de forma única a cada cliente:

SELECT 
    CustomerID, 
    FirstName, 
    LastName, 
    Address 
FROM Customers;

Ten en cuenta que incluir CustomerID no elimina una duplicidad: define correctamente la granularidad del resultado, pues cada fila representa un cliente único, aunque dos clientes compartan nombre, apellido o dirección.

Otra opción es utilizar EXISTS para comprobar relaciones: si el requisito consiste únicamente en obtener los clientes que tienen al menos un pedido, utiliza EXISTS:

SELECT
    c.CustomerID,
    c.FirstName,
    c.LastName
FROM Customers c
WHERE EXISTS (
    SELECT 1
    FROM Orders o
    WHERE o.CustomerID = c.CustomerID
);

Esta consulta expresa directamente la condición de negocio y evita multiplicar las filas de clientes por el número de pedidos relacionados.

Caso 2. Utilizar GROUP BY para calcular agregaciones: si el objetivo es calcular información agregada —por ejemplo, el número de pedidos por cliente—, debe utilizarse GROUP BY:

SELECT
    c.CustomerID,
    c.FirstName,
    c.LastName,
    COUNT(o.OrderID) AS NumberOfOrders
FROM Customers c
INNER JOIN Orders o
    ON c.CustomerID = o.CustomerID
GROUP BY
    c.CustomerID,
    c.FirstName,
    c.LastName;

En este caso, la agrupación responde al requisito funcional: cada fila representa un cliente y contiene una métrica calculada sobre sus pedidos.

Caso 3.  Utilizar DISTINCT para obtener valores únicos: cuando la unicidad forma parte explícita del resultado esperado, DISTINCT es lo adecuado. Por ejemplo, para conocer los países en los que existen clientes registrados, su uso es correcto porque el requisito consiste en obtener una sola fila por país.

SELECT DISTINCT
    Country
FROM Customers;

Antes de utilizar DISTINCT, determina qué entidad representa cada fila y qué operación responde realmente al requisito:

• EXISTS, para comprobar si existen registros relacionados.
• GROUP BY, para agrupar datos y calcular métricas.
• DISTINCT, para obtener valores o combinaciones únicas.

EVITAR

Evita siempre definir las relaciones en la cláusula WHERE:

SELECT
    c.CustomerID,
    c.Name,
    s.LastSaleDate
FROM Customers c, Sales s
WHERE c.CustomerID = s.CustomerID
  AND s.Status = 'Closed';

Aunque esta sintaxis puede devolver el resultado esperado, mezcla en la misma cláusula las condiciones de unión y los filtros de negocio. A medida que se incorporan más tablas y condiciones, resulta más difícil comprobar que todas las relaciones necesarias están correctamente definidas.

El riesgo aparece cuando una condición de unión se omite o se especifica de forma incorrecta:

SELECT
    c.CustomerID,
    c.Name,
    s.LastSaleDate
FROM Customers c, Sales s
WHERE s.Status = 'Closed';

Al no existir una condición que relacione Customers con Sales, la consulta genera un producto cartesiano: cada cliente se combina con todas las ventas que cumplen el filtro.

El número de filas resultante puede crecer de forma multiplicativa. Si una tabla contiene 1.000 clientes y la otra 10.000 ventas, el cruce podría generar hasta 10 millones de combinaciones antes de completar el procesamiento. Esto puede provocar resultados incorrectos, tiempos de ejecución muy elevados, agotamiento de recursos e incluso afectar a la estabilidad del sistema.

BUENA PRÁCTICA

La buena práctica es utilizar JOIN ... ON:

SELECT
    c.CustomerID,
    c.Name,
    s.LastSaleDate
FROM Customers c
INNER JOIN Sales s
    ON c.CustomerID = s.CustomerID
WHERE s.Status = 'Closed';

La sintaxis explícita permite distinguir claramente:

• ON, para definir cómo se relacionan las tablas.
• WHERE, para determinar qué filas deben conservarse.

Esta separación facilita la revisión de la consulta, permite detectar relaciones ausentes y reduce el riesgo de introducir cruces accidentales cuando se añaden nuevas tablas o filtros.

También hace explícito el tipo de relación requerido:

• INNER JOIN, cuando solo deben conservarse los registros coincidentes.
• LEFT JOIN, cuando deben mantenerse todos los registros de la tabla izquierda.
• RIGHT JOIN, cuando deben mantenerse todos los registros de la tabla derecha.
• FULL JOIN, cuando deben conservarse los registros de ambas tablas, exista o no correspondencia.

En los outer joins, colocar una condición en ON o en WHERE puede modificar el resultado. Por ello, es especialmente importante separar correctamente las condiciones de relación de los filtros posteriores.

Otra opción es utilizar CROSS JOIN cuando el producto cartesiano sea intencionado. Un producto cartesiano puede responder a un requisito válido, por ejemplo, para generar todas las combinaciones posibles entre fechas y regiones:

SELECT
    d.CalendarDate,
    r.RegionName
FROM CalendarDates d
CROSS JOIN Regions r;

Cuando este comportamiento sea deliberado, utiliza CROSS JOIN de forma explícita. Así queda claro que la multiplicación de filas forma parte del diseño y no procede de una condición de unión olvidada.

EVITAR

Evita utilizar HAVING para filtrar filas individuales. Supongamos que queremos analizar las ventas realizadas durante 2026. El intervalo temporal debe aplicarse antes de agrupar los registros:

SELECT
    c.CustomerID,
    c.Name,
    COUNT(s.SalesID) AS NumberOfSales
FROM Customers c
INNER JOIN Sales s
    ON c.CustomerID = s.CustomerID
GROUP BY
    c.CustomerID,
    c.Name
HAVING s.SaleDate >= DATE '2026-01-01'
   AND s.SaleDate < DATE '2027-01-01';

Esta formulación no es adecuada porque “SaleDate” representa una condición sobre las filas individuales de ventas, no sobre el resultado de la agregación. Además, al no formar parte del GROUP BY ni estar agregada, la expresión no será válida en muchos motores SQL.

Evita utilizar HAVING como sustituto general de WHERE. Es cierto que algunos motores pueden reescribir internamente ciertas condiciones de HAVING —sobre todo cuando hacen referencia a columnas de agrupación— y aplicarlas como si fueran un filtro de WHERE durante la optimización. Pero esta capacidad del optimizador no debe condicionar cómo escribes la consulta: no todos los motores lo hacen, y el comportamiento puede variar según la versión o la configuración. Expresa cada condición según su función:

• Utiliza WHERE para decidir qué filas entran en la agregación.
• Utiliza HAVING para decidir qué grupos permanecen después de calcularla.

Esta separación mejora la legibilidad, facilita el mantenimiento y evita procesar innecesariamente datos que podrían haberse descartado antes.

BUENA PRÁCTICA

La buena práctica para nuestro ejemplo sería aplicar el filtro de filas con WHERE:

SELECT
    c.CustomerID,
    c.Name,
    COUNT(s.SalesID) AS NumberOfSales
FROM Customers c
INNER JOIN Sales s
    ON c.CustomerID = s.CustomerID
WHERE s.SaleDate >= DATE '2026-01-01'
  AND s.SaleDate < DATE '2027-01-01'
GROUP BY
    c.CustomerID,
    c.Name;

El motor filtra primero las ventas correspondientes a 2026 y agrupa únicamente las filas que cumplen esa condición. Esto evita incorporar a la agregación registros que posteriormente no formarán parte del resultado.

Cuando la condición depende de un resultado agregado, utiliza HAVING para filtrar resultados agregados. Si el requisito consiste en obtener únicamente los clientes que realizaron al menos diez ventas durante 2026, deben utilizarse ambas cláusulas:

SELECT
    c.CustomerID,
    c.Name,
    COUNT(s.SalesID) AS NumberOfSales
FROM Customers c
INNER JOIN Sales s
    ON c.CustomerID = s.CustomerID
WHERE s.SaleDate >= DATE '2026-01-01'
  AND s.SaleDate < DATE '2027-01-01'
GROUP BY
    c.CustomerID,
    c.Name
HAVING COUNT(s.SalesID) >= 10;

En esta consulta:

• WHERE selecciona las ventas realizadas durante 2026.
• GROUP BY agrupa esas ventas por cliente.
• HAVING conserva únicamente los clientes cuyo número de ventas es igual o superior a diez.

EVITAR

Se debe evitar buscar en cualquier posición cuando el requisito es «empieza por». Supongamos que queremos obtener las ciudades cuyo nombre empieza por “Char”:

SELECT
    City
FROM Customers
WHERE City LIKE '%Char%';

El comodín situado al principio indica que puede existir cualquier texto antes de “Char”. Por tanto, la consulta no busca únicamente ciudades que comiencen por esa cadena, sino cualquier valor que la contenga en alguna posición. Además de resultados como “Charleston”, “Charlotte” o “Charlton”, podría devolver nombres como “Cape Charles”, “Crab Orchard” o cualquier otro valor que contenga la cadena “Char” en su interior.

Esta búsqueda suele exigir examinar una parte mucho mayor de los datos y, en condiciones normales, dificulta el aprovechamiento de un índice B-tree convencional.

BUENA PRÁCTICA

Cuando el requisito sea encontrar valores que empiezan por una cadena, coloca el comodín únicamente al final:

SELECT
    City
FROM Customers
WHERE City LIKE 'Char%';

Esta expresión representa correctamente la intención de la consulta: el valor debe comenzar por “Char”, aunque pueda contener cualquier texto a continuación. Además de ser más precisa, una búsqueda por prefijo puede permitir que el motor utilice índices u otros mecanismos de acceso optimizado, dependiendo de la base de datos, el tipo de índice y la configuración de ordenación o collation.

¿Cuándo el comodín inicial sí es necesario? Una búsqueda con comodín inicial no es incorrecta cuando el requisito consiste realmente en localizar una cadena en cualquier posición:

SELECT
    City
FROM Customers
WHERE City LIKE '%Charles%';

En este caso, eliminar el primer comodín cambiaría el significado funcional de la consulta. La solución no consiste en reescribirla como una búsqueda por prefijo, sino en evaluar si la plataforma dispone de mecanismos específicos para búsquedas de texto o subcadenas, como índices especializados, búsqueda de texto completo o servicios de optimización.

Si este tipo de búsqueda se ejecuta con frecuencia sobre grandes volúmenes de datos, debe revisarse con el responsable de la plataforma y validarse mediante el plan de ejecución.

EVITAR

Debes evitar confiar únicamente en “LIMIT”:

SELECT
    CustomerID,
    COUNT(*) AS NumberOfSales
FROM Sales
WHERE SaleDate >= DATE '2026-01-01'
GROUP BY
    CustomerID
LIMIT 10;

Esta consulta devuelve únicamente diez filas, pero el límite se aplica después del filtro y de la agregación. Para calcular el número de pedidos por cliente, el motor puede tener que procesar todas las filas que cumplen la condición y construir todos los grupos antes de limitar el resultado. Por tanto, LIMIT puede reducir el volumen de información transferido y mostrado, pero no debe interpretarse como una garantía de menor consumo computacional.

Además, sin una cláusula ORDER BY, los diez registros devueltos no siguen un orden determinado y pueden variar entre ejecuciones. Si necesitas comprobar un resultado concreto o reproducible, debes establecer expresamente el criterio de ordenación.

Ten en cuenta que LIMIT no equivale a una muestra representativa: LIMIT 10 devuelve diez filas del resultado, pero no garantiza que constituyan una muestra aleatoria o representativa del conjunto completo.

Si el objetivo es validar únicamente la estructura y el contenido de la consulta, un subconjunto controlado puede ser suficiente. Si necesitas realizar una prueba estadística o evaluar la distribución real de los datos, utiliza los mecanismos de muestreo disponibles en el motor de origen y comprueba su sintaxis y comportamiento específico.

BUENA PRÁCTICA

En nuestro caso, la buena práctica consiste en reducir el conjunto de entrada. Para validar la consulta, acota primero los datos que entrarán en las operaciones más costosas. Puedes utilizar un intervalo temporal reducido, un rango de identificadores, una región, un cliente o cualquier otro criterio controlado y representativo del caso de uso.

SELECT
    CustomerID,
    COUNT(*) AS NumberOfSales
FROM Sales
WHERE SaleDate >= DATE '2026-01-01'
  AND SaleDate < DATE '2026-01-08'
GROUP BY
    CustomerID
ORDER BY
    NumberOfSales DESC,
    CustomerID
LIMIT 10;

En este ejemplo, la consulta se valida inicialmente sobre una semana de datos. El motor agrega un conjunto de entrada más reducido y devuelve un resultado ordenado y reproducible. Una vez comprobada la lógica, amplía progresivamente el periodo o el volumen procesado y revisa cómo evoluciona el plan de ejecución, la duración y el consumo de recursos.

¿Cuándo puede reducir realmente el trabajo? En consultas sencillas, sin agregaciones ni ordenaciones costosas, un límite puede permitir que el motor detenga la ejecución después de encontrar las filas necesarias:

SELECT
    SalesID,
    CustomerID,
    DaleDate,
    TotalAmount
FROM Sales
WHERE SaleDate >= DATE '2026-01-01'
ORDER BY
    SaleID
LIMIT 100;

Sin embargo, el ahorro efectivo depende del plan de ejecución, los índices, el particionado, el almacenamiento y las capacidades del motor. Algunos CDW también pueden aplicar optimizaciones específicas para consultas que combinan ORDER BY y LIMIT, pero no debe asumirse que se aplicarán en todos los casos.

Por otra parte, no utilices LIMIT como única protección en producción. Antes de ejecutar una consulta potencialmente costosa:

• Revisa el plan mediante EXPLAIN o la herramienta equivalente del motor.
• Prueba la lógica sobre un intervalo o segmento reducido.
• Utiliza, cuando sea posible, un entorno de desarrollo, una réplica o un warehouse separado.
• Establece límites de tiempo y recursos.
• Comprueba el volumen leído, las filas procesadas y el coste estimado.
• Amplía el alcance de forma progresiva.

La sintaxis para limitar resultados varía según el motor. PostgreSQL, Snowflake, Redshift y MySQL admiten LIMIT; otros sistemas utilizan construcciones como FETCH FIRST, OFFSET ... FETCH o TOP.

EVITAR

Lo que debes evitar es trasladar una consulta incorrecta a otra franja horaria. Una condición de unión ausente, un producto cartesiano accidental o una dependencia circular deben corregirse antes de ejecutar el proceso. Programarlos durante la noche puede reducir temporalmente su impacto sobre los usuarios, pero no elimina el riesgo de saturación, fallo o consumo descontrolado.

Del mismo modo, elementos como DISTINCT, las subconsultas o la consulta de varios esquemas no son necesariamente ineficientes. Su coste depende de cómo los procese el motor y del volumen de datos implicado.

BUENA PRÁCTICA

Lo adecuado es separar las cargas batch de las interactivas. Los procesos de extracción, transformación, consolidación o reconstrucción completa suelen ser mejores candidatos para una ejecución programada. Siempre que los requisitos de actualización lo permitan, deben situarse en una ventana con menor actividad y coordinarse con otros procesos de la plataforma.

La ventana adecuada no tiene que ser necesariamente de madrugada. En organizaciones internacionales o con actividad continua, debe definirse a partir de los patrones reales de uso, las zonas horarias, los cierres operativos y las demás cargas programadas.

EVITAR

Debes evitar validar únicamente con unas pocas filas. Una muestra demasiado pequeña o arbitraria puede confirmar que una expresión funciona, pero no necesariamente que el modelo sea correcto. Puede no incluir:

• Relaciones uno a muchos o muchos a muchos.
• Claves duplicadas o valores nulos.
• Registros sin correspondencia entre tablas.
• Fechas, importes o categorías excepcionales.
• Combinaciones de filtros que generan resultados incorrectos.
• Distribuciones de datos que afectan al rendimiento.

Utiliza una muestra controlada y representativa, que incluya tanto los casos habituales como los casos límite. Después, amplía progresivamente el volumen para comprobar cómo escala el modelo.

BUENA PRÁCTICA

Lo adecuado es validar por capas. Antes de llevar un modelo a producción, comprueba al menos cuatro dimensiones.

1. Exactitud funcional. Confirma que las métricas, dimensiones y filtros responden al requisito de negocio y se reconcilian con una fuente de referencia.
2. Integridad del modelo. Revisa las claves, la cardinalidad, las rutas entre tablas y la granularidad esperada. Comprueba especialmente que los JOIN y las relaciones visuales no multipliquen registros ni provoquen agregaciones inconsistentes.
3. Rendimiento. Mide la duración, el volumen procesado y el consumo de recursos con datos representativos. Una transformación que funciona correctamente sobre mil filas puede comportarse de forma muy diferente cuando se aplica a cientos de millones.
4. Seguridad. Valida que las reglas de acceso, la segmentación de datos y los filtros de usuario producen el resultado esperado para cada perfil antes de compartir el modelo o el dashboard.