Pregunta de la teoría de consultas SQL - consultas de declaración única vs consultas de declaración múltiple

Question

Cuando escribo consultas SQL, a menudo pienso que "no hay forma de hacer esto con una sola consulta". Cuando eso sucede, a menudo recurro a procedimientos almacenados o funciones con valores de tabla de varias declaraciones que usan tablas temporales (de un tipo u otro) y terminan simplemente combinando los resultados y devolviendo la tabla de resultados.

Me pregunto si alguien sabe, simplemente como una cuestión de teoría, si debería ser posible escribir CUALQUIER consulta que devuelva un solo conjunto de resultados como una sola consulta (no varias declaraciones). Obviamente, estoy ignorando los puntos relevantes tales como la legibilidad del código y el mantenimiento, incluso el rendimiento/eficiencia de la consulta. Se trata más de teoría, se puede hacer ... y no se preocupe, ciertamente no planeo comenzar a forzarme a escribir una consulta de declaración única cuando el enunciado múltiple se adapte mejor a mi propósito en todos los casos, pero podría hacerme pensar dos veces o un poco más sobre si hay una forma viable de obtener el resultado de una sola consulta.

Supongo que algunos parámetros están en orden. Estoy pensando en una base de datos relacional (como MS SQL) con tablas que siguen las mejores prácticas comunes (como que todas las tablas tengan una clave principal, etc.).

Nota: (. Referencia al material de banda o algo similar) con el fin de ganar 'respuesta aceptada' en esto, usted tendrá que proporcionar una prueba definitiva

Answer 1

Al menos con la versión más reciente de Oracle es absolutamente posible. Tiene una 'cláusula modelo' que hace que la sql turing se complete. (http://blog.schauderhaft.de/2009/06/18/building-a-turing-engine-in-oracle-sql-using-the-model-clause/). Por supuesto, esto es todo con la limitación habitual de que realmente no tenemos tiempo y memoria ilimitados.

Para un dialecto sql normal sin estas ablaciones, no creo que sea posible.

Una tarea que no puedo ver cómo implementar en 'sql normal' sería: Supongamos una tabla con una sola columna de tipo entero

Para cada fila 'toma el valor en la fila actual y recorra esas muchas filas, busque ese valor, vaya esas muchas filas hacia atrás, y continúe hasta que obtenga el mismo valor dos veces consecutivas y lo devuelva como resultado '.

Answer 2

creo que es posible. He trabajado con consultas muy difíciles, consultas muy largas y, a menudo, es posible hacerlo con una sola consulta. Pero la mayoría de las veces, es más difícil de mantener, por lo que si lo haces con una sola consulta, asegúrate de comentar tu consulta detenidamente.

Nunca he encontrado algo que no se haya podido hacer en una sola consulta.
Pero a veces es mejor hacerlo en más de una consulta.

Answer 3

No puedo probarlo, pero creo que la respuesta es un sí cauteloso, siempre que el diseño de su base de datos se realice correctamente. Generalmente, se ve obligado a escribir varias declaraciones para obtener un resultado determinado, lo que indica que su esquema puede necesitar algunas mejoras.

Answer 4

Yo diría que "sí" pero no puedo probarlo. Sin embargo, mi principal proceso de pensamiento:

• Cualquier seleccione debe ser un conjunto basado operación

• Su hipótesis es que se trata de conjuntos matemáticamente correctos (es decir normalizaron correctamente) la teoría

• Conjunto debe garantizar que es posible

Otros pensamientos:

• La instrucción SELECT múltiple a menudo carga tablas temporales/variables de tabla. Estos pueden derivarse o separarse en CTE.

• Todo tratamiento RBAR (para bien o para mal) ahora ser tratados CRUZ/exterior aplica a las tablas derivadas

• UDF serían clasificados como "trampa" en este contexto que siento, porque le permite poner a Seleccione en otro módulo en lugar de en su sola

• No se escribe permitido en el "antes" secuencia de LMD: actúa sobre el estado de selección para aceptar

• Ha visto una parte del código en nuestra tienda ?

Editar, glosario

• RBAR = Row By Agonising Row
• CTE = Common Table Expression
• UDF = User Defined Function

Editar: SOLICITUDES: hacer trampa?

SELECT 
    * 
FROM 
    MyTable1 t1 
    CROSS APPLY 
    (
     SELECT * FROM MyTable2 t2 
     WHERE t1.something = t2.something 
    ) t2 

Answer 5

En teoría sí, si utiliza funciones o un tortuoso laberinto de APLICACIONES EXTERNAS o sub-consultas; sin embargo, para la legibilidad y el rendimiento, siempre terminamos yendo con tablas temporales y procedimientos almacenados de instrucciones múltiples.

Como alguien comentó anteriormente, esto es generalmente una señal de que su estructura de datos está empezando a oler; no es que sea malo, pero tal vez es hora de desnormalizar por razones de rendimiento (sucede lo mejor para nosotros), o tal vez poner una capa de consulta desnormalizada frente a sus datos "reales" normalizados.