¿Volvería a enviar este SQL simple para volver a trabajar?

Question

Tenemos una aplicación web en la cual los usuarios realizan consultas ad-hoc basadas en los parámetros que se han ingresado. También podría mencionar que el tiempo de respuesta es de gran importancia para los usuarios.

La página web construye dinámicamente un SQL para ejecutar en función de los parámetros ingresados. Por ejemplo, si el usuario introduce "1" para "Unidad de Negocio" Construimos un SQL como esto:

SELECT * FROM FACT WHERE 
BUSINESS_UNIT = '1' 
--AND other criteria based on the input params 

he encontrado que, cuando el usuario no especifica un BUSINESS_UNIT la siguiente consulta se construye

SELECT * FROM FACT WHERE 
BUSINESS_UNIT LIKE '%' 
--AND other criteria based on the input params 

En mi humilde opinión, esto es innecesariamente (si no groseramente) ineficaz y garantiza el mal envío del código para la modificación, pero como tengo una tasa mucho más alta de envío de código para la reelaboración que otros, creo que puedo ganar una reputación como " demasiado quisquilloso."

Si esta es una pregunta inapropiada porque no es una codificación Q directa, avíseme y la eliminaré inmediatamente. ¡Estoy muy confundido si las preguntas subjetivas como esta están permitidas o no! Estaré viendo tus respuestas.

ty

---

Actualización:

estoy usando una base de datos Oracle.

Mi impresión es que Oracle no optimiza "LIKE '%'" eliminando la condición y que dejarla activa es menos eficiente. ¿Alguien podría confirmar?

Answer 1

Aunque eso parece bastante ineficiente, simplemente lo probé en SQL Server, y el optimizador de consultas fue lo suficientemente inteligente como para filtrarlo.

En otras palabras,

SELECT * FROM FACT WHERE 
BUSINESS_UNIT LIKE '%' 

y

SELECT * FROM FACT 

genera el mismo plan de consulta exacta. Entonces no debería haber una diferencia en el rendimiento (dependiendo de tu motor de DB, supongo), aunque parece un poco descuidado.

Eso puede afectar su decisión de devolverlo o no. Personalmente, probablemente lo haría, pero si ya estás bajo una nube, entonces es algo en lo que probablemente puedas relajarte, al menos en términos de rendimiento.

Answer 2

Lo enviaría de vuelta y me gusta la pregunta.

Toda revisión del código es en cierta medida subjetiva. Los criterios deben basarse en una serie de factores.

• Funciona.

• ¿Cumple con las expectativas razonables de rendimiento, mantenimiento, facilidad de uso y escalabilidad

Aunque no he probado este particular construcción - Sospecho que (al igual que usted) este código va a hacer cosas horribles a su servidor SQL Por lo tanto, el rendimiento y la escalabilidad son cuestionados.

Answer 3

Esa consulta, con el BUSINESS_UNIT LIKE '%', no se ve muy eficiente - supongo que va a obligar a un análisis completo de la mesa ...

Así que, sí, me gustaría tratar de tener esa consulta reelaborada , para hacer frente a ese tipo de situación de manera adecuada o, al menos, Informaría de ese problema a través de nuestro rastreador de errores(No estoy seguro de la prioridad que asignaría, pero, aún así, el problema sería registrado en alguna parte, y alguien lo corregirá algún día, cuando no haya un problema de mayor prioridad para tratar).

Answer 4

El autor quería una declaración ficticia para que pudiera agregar "y" a todas las afirmaciones posteriores. cambiarlo a una mejor declaración "no operativa" como 1 == 1 ayudaría. O podrían hacer un poco más de trabajo e insertar el "dónde" inteligentemente.

Answer 5

SELECCIONAR * es una bandera roja. Especifique una lista de columnas para la consulta.

Answer 6

las dos consultas son completamente diferentes (desde el punto de vista de un conjunto de resultados)

SELECT * FROM FACT; 

y

SELECT * FROM FACT WHERE 
BUSINESS_UNIT LIKE '%'; 

La primera devolverá todas las filas, el segundo, si hay NULL valores esas filas no se devolverán porque cualquier cosa en comparación con NULL es NULL y, por lo tanto, no satisface el predicado. Así es como funcionaría en Oracle.

Answer 7

que sería preguntarse por qué variables se unen no se están utilizando (a menos que haya una buena razón en casos particulares):

SELECT * FROM FACT WHERE 
BUSINESS_UNIT = '1' 

Por qué no es:

SELECT * FROM FACT WHERE 
BUSINESS_UNIT = :bu