example - sp_execute sql server

¿Por qué alguien usaría WHERE 1=1 AND<conditions> en una cláusula SQL?

Question

¿Por qué alguien usaría WHERE 1=1 AND <conditions> en una cláusula SQL (cualquiera de los dos SQL obtenido a través de cadenas concatenadas, cualquiera de las definiciones de vista)

He visto en algún lugar que esto se usaría para proteger contra la inyección de SQL, pero parece muy extraño.

Si hay inyección WHERE 1 = 1 AND injected OR 1=1 tendría el mismo resultado que la injected OR 1=1 .

Edición posterior: ¿Qué pasa con el uso en una definición de vista?

Gracias por sus respuestas.

Aún así, no entiendo por qué alguien usaría esta construcción para definir una vista, o la usaría dentro de un procedimiento almacenado.

Toma esto por ejemplo:

CREATE VIEW vTest AS
SELECT FROM Table WHERE 1=1 AND table.Field=Value

Answer 1

¿Por qué alguien usaría DONDE 1 = 1 Y <proper conditions>

He seen marcos parecidos a este tipo de aplicaciones ( blush ), ya que esto permite aplicar prácticas de análisis perezoso a las palabras clave WHERE y AND Sql.

Por ejemplo (estoy usando C # como ejemplo aquí), considere el análisis condicional de los siguientes predicados en un string builder consulta Sql:

var sqlQuery = "SELECT * FROM FOOS WHERE 1 = 1"
if (shouldFilterForBars)
{
    sqlQuery = sqlQuery + " AND Bars > 3";
}
if (shouldFilterForBaz)
{
    sqlQuery = sqlQuery + " AND Baz < 12";
}

El "beneficio" de WHERE 1 = 1 significa que no se necesita ningún código especial:

• Para AND : si es cero, se deben aplicar uno o ambos predicados (Bars y Baz), lo que determinaría si se requiere el primer AND . Como ya tenemos al menos un predicado con 1 = 1 , significa que AND siempre está bien.
• Para ningún predicado en absoluto: en el caso de que haya predicados CERO, entonces se debe eliminar el WHERE . Pero, de nuevo, podemos ser perezosos, porque nuevamente somos garantía de al menos un predicado.

Obviamente, esto es una mala idea y recomendaría utilizar un marco de acceso a datos establecido u ORM para analizar predicados opcionales y condicionales de esta manera.

Answer 2

1 = 1 expresión se usa comúnmente en el código SQL generado. Esta expresión puede simplificar el código de generación de SQL reduciendo el número de sentencias condicionales.

Answer 3

Después de revisar todas las respuestas, decidí realizar un experimento como

SELECT
*
FROM MyTable

WHERE 1=1

Entonces lo comprobé con otros números.

WHERE 2=2
WHERE 10=10
WHERE 99=99

ect Habiendo realizado todas las comprobaciones, la consulta ejecutar ciudad es la misma. incluso sin la cláusula where. No soy fan de la sintaxis.

Answer 4

En realidad, he visto este tipo de cosas utilizadas en los informes BIRT. La consulta pasada al tiempo de ejecución de BIRT es de la forma:

select a,b,c from t where a = ?

y el ''?'' se reemplaza en tiempo de ejecución por un valor de parámetro real seleccionado en un cuadro desplegable. Las opciones en el desplegable están dadas por:

select distinct a from t
union all
select ''*'' from sysibm.sysdummy1

para que obtengas todos los valores posibles más " * ". Si el usuario selecciona " * " en el cuadro desplegable (lo que significa que deben seleccionarse todos los valores de a), la consulta debe ser modificada (por Javascript) antes de ejecutarse.

Desde el "?" es un parámetro posicional y DEBE permanecer allí para que otras cosas funcionen, el Javascript modifica la consulta para que sea:

select a,b,c from t where ((a = ?) or (1==1))

Básicamente, eso elimina el efecto de la cláusula where y al mismo tiempo deja el parámetro posicional en su lugar.

También he visto el caso AND utilizado por los codificadores perezosos mientras creaba dinámicamente una consulta SQL.

Digamos que tiene que crear dinámicamente una consulta que comience con select * from t y verifique:

• el nombre es bob; y
• el sueldo es> $ 20,000

algunas personas agregarían la primera con un DÓNDE y las siguientes con una AND así:

select * from t where name = ''Bob'' and salary > 20000

Los programadores perezosos (y eso no es necesariamente un rasgo malo ) no distinguirían entre las condiciones agregadas, comenzarían con select * from t where 1=1 y solo agregarían las cláusulas AND después de eso.

select * from t where 1=1 and name = ''Bob'' and salary > 20000

Answer 5

Encontré útil este patrón cuando estoy probando o haciendo doble comprobación de cosas en la base de datos, por lo que puedo comentar rápidamente otras condiciones:

CREATE VIEW vTest AS
SELECT FROM Table WHERE 1=1 
AND Table.Field=Value
AND Table.IsValid=true

se convierte en:

CREATE VIEW vTest AS
SELECT FROM Table WHERE 1=1 
--AND Table.Field=Value
--AND Table.IsValid=true

Answer 6

Este es un ejemplo estrechamente relacionado: usar una declaración SQL MERGE para actualizar la tabla de destino utilizando todos los valores de la tabla de origen donde no hay un atributo común en el que unirse, por ejemplo

MERGE INTO Circles
   USING 
      (
        SELECT pi
         FROM Constants
      ) AS SourceTable
   ON 1 = 1
WHEN MATCHED THEN 
  UPDATE
     SET circumference = 2 * SourceTable.pi * radius;

Answer 7

Esto es útil en el caso de que tenga que usar una consulta dinámica en la que en la cláusula tiene que agregar algunas opciones de filtro. Al igual que si incluyes las opciones 0 para el estado está inactivo, 1 para activo. Basado en las opciones, solo hay dos opciones disponibles (0 y 1), pero si desea mostrar Todos los registros, es conveniente incluir en donde cerca 1 = 1. Vea la siguiente muestra:

Declare @SearchValue    varchar(8) 
Declare @SQLQuery varchar(max) = ''
Select [FirstName]
    ,[LastName]
    ,[MiddleName]
    ,[BirthDate]
,Case
    when [Status] = 0 then ''''Inactive''''
    when [Status] = 1 then ''''Active''''
end as [Status]''

Declare @SearchOption nvarchar(100)
If (@SearchValue = ''Active'')
Begin
    Set @SearchOption = '' Where a.[Status] = 1''
End

If (@SearchValue = ''Inactive'')
Begin
    Set @SearchOption = '' Where a.[Status] = 0''
End

If (@SearchValue = ''All'')
Begin
    Set @SearchOption = '' Where 1=1''
End

Set @SQLQuery = @SQLQuery + @SearchOption

Exec(@SQLQuery);

Answer 8

Generalmente hago esto cuando estoy creando SQL dinámico para un informe que tiene muchos valores desplegables que un usuario puede seleccionar. Como el usuario puede o no seleccionar los valores de cada menú desplegable, terminamos teniendo dificultades para determinar qué condición fue la primera cláusula donde. Así que rellenamos la consulta con a where 1=1 al final y agregamos todas las cláusulas where después de eso.

Algo como

select column1, column2 from my table where 1=1 {name} {age};

Luego construimos la cláusula where de esta manera y la pasamos como un valor de parámetro

string name_whereClause= ddlName.SelectedIndex > 0 ? "AND name =''"+ ddlName.SelectedValue+ "''" : "";

Como la selección de la cláusula Where es desconocida para nosotros en el tiempo de ejecución, esto nos ayuda mucho a encontrar si incluir un ''AND'' or ''WHERE''.

Answer 9

Indirectamente relevante: cuando se usa 1 = 2:

CREAR TABLA New_table_name como select * FROM Old_table_name WHERE 1 = 2;

esto creará una nueva tabla con el mismo esquema que la tabla anterior. (Muy útil si desea cargar algunos datos para comparaciones)

Answer 10

La primera vez que encontré esto fue con ADO y Asp clásico, la respuesta que obtuve fue: rendimiento. si haces una recta

Select * from tablename

y pase eso como un comando / texto de sql obtendrá un notable aumento de rendimiento con el

Where 1=1

Agregado, era una diferencia visible. algo relacionado con los encabezados de las mesas que se devuelven tan pronto como se cumple la primera condición, o alguna otra locura, de todos modos, aceleró las cosas.

Answer 11

Lo he visto usado cuando el número de condiciones puede ser variable.

Puedes concatenar condiciones usando una cadena "AND". Luego, en lugar de contar el número de condiciones que está pasando, coloque un "WHERE 1 = 1" al final de su declaración de SQL y arroje las condiciones concatenadas.

Básicamente, le ahorra tener que hacer una prueba de condiciones y luego agregar una cadena "DONDE" antes de ellos.

Answer 12

Parece una forma perezosa de saber siempre que su cláusula WHERE ya está definida y le permite seguir agregando condiciones sin tener que verificar si es la primera.

Answer 13

Si bien puedo ver que 1 = 1 sería útil para el SQL generado, una técnica que uso en PHP es crear una matriz de cláusulas y luego hacer

implode (" AND ", $clauses);

evitando así el problema de tener un AND o un arrastre. Obviamente, esto solo es útil si sabe que va a tener al menos una cláusula.

Answer 14

Si la lista de condiciones no se conoce en el momento de la compilación y, en cambio, se construye en el tiempo de ejecución, no tiene que preocuparse de si tiene una o más de una condición. Puedes generarlos todos como:

and <condition>

y concatenarlos todos juntos. Con 1=1 al inicio, la inicial and tiene algo con qué asociarse.

Nunca he visto esto usado para ningún tipo de protección contra inyecciones, como usted dice, no parece que ayude mucho. Lo he visto usado como una conveniencia de implementación. El motor de consulta SQL terminará ignorando el 1=1 por lo que no debería tener impacto en el rendimiento.

Answer 15

Si vino aquí buscando WHERE 1 , tenga en cuenta que WHERE 1 y WHERE 1=1 son idénticos. WHERE 1 se usa raramente porque algunos sistemas de base de datos lo rechazan considerando que WHERE 1 realmente no es booleano.

Answer 16

Solo agregando un código de ejemplo a la respuesta de Greg:

dim sqlstmt as new StringBuilder
sqlstmt.add("SELECT * FROM Products")
sqlstmt.add(" WHERE 1=1") 

''''// From now on you don''t have to worry if you must 
''''// append AND or WHERE because you know the WHERE is there
If ProductCategoryID <> 0 then
  sqlstmt.AppendFormat(" AND ProductCategoryID = {0}", trim(ProductCategoryID))
end if
If MinimunPrice > 0 then
  sqlstmt.AppendFormat(" AND Price >= {0}", trim(MinimunPrice))
end if

Answer 17

Usar un predicado como 1=1 es una sugerencia normal que a veces se usa para forzar que el plan de acceso use o no un escaneo de índice. La razón por la que se usa esto es cuando está utilizando una consulta unida anidada con muchos predicados en la cláusula where, donde a veces, incluso utilizando todos los índices, hace que el plan de acceso lea cada tabla: una exploración completa de la tabla. Esta es solo una de las muchas sugerencias utilizadas por los DBA para engañar a un dbms para que use una ruta más eficiente. Simplemente no tires uno; necesita un dba para analizar la consulta, ya que no siempre funciona.

Answer 18

donde 1 = 0, Esto se hace para verificar si la tabla existe. No sé por qué se utiliza 1 = 1.