tables - sql server left and right join together
Transact-SQL-sub consulta o left-join? (7)
En la mayoría de los casos, el optimizador los tratará de la misma manera.
Tiendo a preferir el segundo, porque tiene menos anidamiento, lo que hace que sea más fácil de leer y de mantener. Empecé a usar las expresiones de tabla comunes de SQL Server para reducir la anidación también por la misma razón.
Además, la segunda sintaxis es más flexible si hay agregados adicionales que se pueden agregar en el futuro además de COUNT, como MIN (algunos_cables), MAX (), AVG (), etc.
Tengo dos tablas que contienen Tareas y Notas, y quiero recuperar una lista de tareas con el número de notas asociadas para cada una. Estas dos consultas hacen el trabajo:
select t.TaskId, (select count(n.TaskNoteId) from TaskNote n where n.TaskId = t.TaskId) ''Notes'' from Task t -- or select t.TaskId, count(n.TaskNoteId) ''Notes'' from Task t left join TaskNote n on t.TaskId = n.TaskId group by t.TaskId
¿Hay alguna diferencia entre ellos y debería usar uno sobre el otro, o son solo dos formas de hacer el mismo trabajo? Gracias.
En pequeños conjuntos de datos, se lavan cuando se trata de rendimiento. Cuando se indexa, el LOJ es un poco mejor.
He descubierto en grandes conjuntos de datos que una unión interna (una unión interna también funcionará) superará a la subconsulta por un factor muy grande (lo siento, no hay números).
No hay una respuesta clara sobre esto. Debería ver el Plan SQL. En términos de álgebra relacional, son esencialmente equivalentes.
Puede usar cualquiera de ellos, y son semánticamente idénticos. En general, la regla de oro es usar cualquier forma que sea más fácil de leer, a menos que el rendimiento sea un problema.
Si el rendimiento es un problema, entonces experimente con la reescritura de la consulta utilizando el otro formulario. Algunas veces el optimizador usará un índice para una forma, y no para la otra.
Si está utilizando SQL Server Management Studio, puede ingresar ambas versiones en el Query Editor y luego hacer clic con el botón derecho y seleccionar Visualizar plan de ejecución estimado. Le dará dos costos porcentuales relativos al lote. Si se espera que tarden el mismo tiempo, ambos se mostrarán como 50%, en cuyo caso, elija el que prefiera por otros motivos (más fácil de leer, más fácil de mantener, mejor ajustado a sus estándares de codificación, etc.). De lo contrario, puede elegir el que tenga el menor costo porcentual relativo al lote.
Puede usar la misma técnica para ver el cambio de cualquier consulta para mejorar el rendimiento al comparar dos versiones que hacen lo mismo.
Por supuesto, debido a que es un costo relativo al lote, no significa que cualquiera de las consultas sea tan rápida como podría ser: simplemente le indica cómo se comparan entre sí, no a una consulta óptima teórica para obtener los mismos resultados. .
La subconsulta será más lenta ya que se está ejecutando para cada fila en la consulta externa. La unión será más rápida ya que se realiza una vez. Creo que el optimizador de consultas no reescribirá este plan de consulta ya que no puede reconocer la equivalencia.
Normalmente harías una unión y agruparías para este tipo de conteo. Las subconsultas correlacionadas del tipo que muestre son principalmente de interés si tienen que hacer alguna agrupación o predicado más complejo en una tabla que no está participando en otra unión.
Me aseguro de evitar las subconsultas siempre que sea posible. La unión generalmente será más eficiente.