2008-12-02 42 views
5

Estoy tratando de escribir una consulta para una página de búsqueda avanzada en mi sistema de archivo de documentos. Estoy intentando buscar por múltiples parámetros opcionales. Tengo alrededor de 5 parámetros que podrían ser cadenas vacías o cadenas de búsqueda. Sé que no debería tener que verificar cada una como una cadena o vacía y crear un procedimiento almacenado por separado para cada combinación.consulta de búsqueda sql para múltiples parámetros opcionales

Editar: terminamos usando:

ISNULL(COALESCE(@var, a.col), '') = ISNULL(a.col, '') 
+0

Vea también: http://stackoverflow.com/questions/532468/ignoring-a-null-parameter-in-t-sql/532510#532510 –

Respuesta

8

Se puede usar COALESCE (o ISNULL) de esta manera:

WHERE COALESCE(@var1, col1) = col1 
AND COALESCE(@var2, col2) = col2 
AND COALESCE(@var3, col3) = col3 
+2

Esta solución no funcionará si el valor de la columna es NULO porque no puede NULL no se puede probar de esa manera. Si el valor es NULL, la fila se filtrará. Esto no es lo que quieres. –

+0

Llamada de función donde la condición ralentizará el rendimiento. En lugar de usar la función de fusión, llame a esto, donde (@ var1 es nulo o col1 = @ var1) –

1

Se puede retener Oregón en su cláusula WHERE de esta manera:

WHERE 
    (@var1 = '' OR col1 = @var1) AND 
    (@var2 = '' OR col1 = @var2) AND 
    (@var3 = '' OR col1 = @var3) ... 
+0

Si bien esta solución funcionará, es increíblemente costosa. No use O ... en su lugar utilice el ISNULL (ejemplo anterior). –

+2

Esta solución funcionará en TODOS los casos. La solución IsNull/Coalesce solo funcionará bajo circunstancias controladas. Cuando usa Coalesce, todavía está probando una columna para EQUAL un valor. Si el valor en la columna es NULL, no será EQUAL y la fila NO será devuelta. –

0

Puede pasar parámetros opcionales a un procedimiento almacenado, pero el optimizador edificaré un plan basado en las llamadas específicas que realiza a ese proceso. Hay algunos trucos en SQL Server 2005 y posteriores para evitar esto (olfateo de parámetros, sugerencias 'sin compilación', etc.)

Incluso con eso, sin embargo, prefiero construir una vista con el núcleo de la consulta y luego use esa vista en varios procs con los parámetros específicos. Eso permite que SQL optimice como quiera/debería y aún consigo consolidar los detalles de la consulta.

0

Aún mejor es hacer que el parámetro NULL opcional y luego probar en la cláusula WHERE al igual que el caso cadena vacía ...

6

que suelo hacer esto: P

WHERE (@var1 IS NULL OR col1 = @var1) 
AND (@var2 IS NULL OR col2 = @var2) 

...

1

Una alternativa es dinámico ally construyó el SQL en el Procedimiento Almacenado, esto produce el mejor plan posible para la consulta y se creará y utilizará un plan de todos modos (en 2005 y superior).

Cuestiones relacionadas