Respuesta.

En SQL, a menudo se requiere filtrado dinámico: por ejemplo, en informes o búsqueda, cuando los filtros son establecidos por el usuario. Los enfoques principales son:

SQL dinámico: la cadena de consulta se construye sobre la marcha con condiciones solo para los parámetros no vacíos. Esto es flexible, pero requiere centrarse en la protección contra inyecciones SQL (usar parámetros/escapado).
Filtrado condicional a través de OR: usar construcciones (@param IS NULL OR campo = @param) para que las condiciones innecesarias no afecten el resultado, si el parámetro no se establece. Este método es seguro, pero a veces lleva a un uso subóptimo de los índices.

Ejemplo de plantilla para buscar pedidos:

SELECT * FROM Orders
WHERE
    (@CustomerID IS NULL OR CustomerID = @CustomerID)
    AND (@Status IS NULL OR Status = @Status)
    AND (@DateFrom IS NULL OR OrderDate >= @DateFrom)
    AND (@DateTo IS NULL OR OrderDate <= @DateTo);

Pregunta capciosa.

Pregunta: ¿Por qué a veces disminuye el rendimiento al usar el enfoque (@param IS NULL OR Column = @param) — incluso con un índice en Column?

Respuesta: Tal plantilla impide que el optimizador use el índice de manera efectiva, ya que en la condición participa una variable, y la consulta se convierte en un escaneo completo de la tabla en lugar de una búsqueda indexada. Con grandes volúmenes de datos, esto es crítico.

Ejemplo:

WHERE (@name IS NULL OR name = @name)

Esta condición no es lo mismo que simplemente name = @name, lo que no permite a la base de datos usar fácilmente el índice.

Historia

En el servicio de búsqueda de la base de datos de clientes se implementaron "filtros flexibles" a través de la plantilla (@par IS NULL OR Field = @par), y con el aumento en el volumen de pedidos, la velocidad de búsqueda cayó de segundos a minutos — los índices dejaron de funcionar, ya que el optimizador no podía determinar un valor específico.

Historia

En un proyecto de e-commerce, la filtración se construyó a través de SQL dinámico sin parámetros, insertando valores directamente. Las inyecciones permitieron a los usuarios obtener listas de todos los clientes, ya que el filtro era vulnerable — las contraseñas tuvieron que cambiarse urgentemente.

Historia

Los informes de BI se construyeron mediante una plantilla parametrizada sin tener en cuenta que las condiciones OR eliminan los escaneos indexados. En conjuntos de informes de millones, los informes "se quedaban parados", hasta que se reescribió la filtración para una opción óptima con condiciones obligatorias y lógica separada para diferentes combinaciones de parámetros.

¿Cómo implementar correctamente y de manera eficiente la lógica condicional para filtrar datos en SQL, si los parámetros de búsqueda se establecen dinámicamente (por ejemplo, un filtro web con cualquier conjunto de condiciones)?

Respuesta.

Pregunta capciosa.