¿Cuál es el propósito de usar WHERE 1 = 1 en sentencias de SQL?

Question

duplicados posibles:
Why would a sql query have “where 1 = 1”
Why would someone use WHERE 1=1 AND <conditions> in a SQL clause?

he visto que una gran cantidad de diferentes ejemplos de consulta y va a probablemente todos los motores SQL.

Si hay una consulta que no tiene condiciones definidas, las personas (y especialmente los marcos ORM) a menudo agregan la condición siempre verdadera WHERE 1 = 1 o algo así.

Así que en lugar de

SELECT id, name FROM users; 

que utilizar

SELECT id, name FROM users WHERE 1 = 1; 

La única razón posible que podía pensar si va a agregar dinámicamente condiciones que no tienen que preocuparse por despojar a la inicial, pero AND todavía bastante a menudo esta condición 1 = 1 se elimina si hay una condición real en la consulta.

ejemplo

real de CakePHP (generado por el sistema):

(sin condiciones)

SELECT `User`.`id`, `User`.`login` 
FROM `users` AS `User` WHERE 1 = 1 
ORDER BY `User`.`id` ASC; 

(con condiciones)

SELECT `User`.`id`, `User`.`login` 
FROM `users` AS `User` 
WHERE `User`.`login` = 'me@example.com' 
LIMIT 1; 

¿Hay alguna razón para añadir esa condición adicional?

Answer 1

Sí, normalmente es porque comienza como 'donde 1 = 0', para forzar la declaración a fallar.

Es una forma más ingenua de completarlo en una transacción y no comprometerlo al final, para probar su consulta. (Este es el método preferido).

Answer 2

Usar 1 = 1 en realidad no es una buena idea ya que esto puede causar escaneos completos de tabla por sí mismo.

Ver este ->T-SQL 1=1 Performance Hit

Answer 3

Es también una práctica común cuando las personas están la construcción de la consulta SQL mediante programación, es simplemente más fácil comenzar con 'donde 1 = 1' y a continuación, añadiendo 'y customer.id =: custId 'dependiendo de si se proporciona una identificación de cliente. Para que siempre pueda agregar la siguiente parte de la consulta comenzando por 'y ...'.

Answer 4

Como se dijo:

si va a agregar condiciones dinámicamente usted no tiene que preocuparse acerca despojar a la inicial y esa es la única razón podría ser, usted tiene razón.

Answer 5

1 = 1 es ignorado por todos los rdbms.No hay compensación en ejecutar una consulta con WHERE 1 = 1.

La construcción de condiciones dinámicas donde, al igual marcos ORM u otros lo hacen muy a menudo, es más fácil para anexar la verdadera donde las condiciones porque se evita la comprobación de anteponiendo un Y a la condición actual.

stmt += "WHERE 1=1"; 
if (v != null) { 
    stmt += (" AND col = " + v.ToString()); 
} 

Así es como se ve sin 1 = 1.

var firstCondition = true; 
... 
if (v != null) { 
    if (!firstCondition) { 
     stmt += " AND "; 
    } 
    else { 
     stmt += " WHERE "; 
     firstCondition = false; 
    } 
    stmt += "col = " + v.ToString()); 
} 

Answer 6

Las personas lo utilizan porque son intrínsecamente flojas al crear consultas SQL dinámicas. Si comienza con un "where 1 = 1", entonces todas sus cláusulas adicionales solo comienzan con "and" y no tiene que descubrirlo.

No es que haya nada de malo en ser intrínsecamente vago. He visto listas doblemente enlazadas donde una lista "vacía" consta de dos nodos centinelas y usted comienza a procesar en el first->next hasta el last->prev inclusive.

Esto realmente eliminó todo el código de manejo especial para eliminar los nodos first y last. En esta configuración, cada nodo era un nodo intermedio ya que no fue posible eliminar first o last. Se desperdiciaron dos nodos pero el código era más simple y (muy ligeramente) más rápido.

El único otro lugar que he visto en la construcción "1 = 1" está en BIRT. Los informes a menudo usan parámetros posicionales y se modifican con Javascript para permitir todos los valores. Así la consulta:

select * from tbl where col = ? 

cuando el usuario selecciona "*" para el parámetro que se utiliza para col se modifica para leer:

select * from tbl where ((col = ?) or (1 = 1)) 

Esto permite que la nueva consulta a ser utilizada sin perder el tiempo con el parámetro posicional detalles. Todavía hay exactamente uno de esos parámetros. Cualquier DBMS decente (por ejemplo, DB2/z) optimizará esa consulta para eliminar básicamente la cláusula por completo antes de intentar construir un plan de ejecución, por lo que no hay compensación.