¿Cuándo debo usar la aplicación cruzada sobre la unión interna?

¿Cuál es el propósito principal de usar CROSS APPLY ?

He leído (vagamente, a través de publicaciones en Internet) que cross applypuede ser más eficiente al seleccionar sobre conjuntos de datos grandes si está particionando. (La paginación viene a la mente)

También sé que CROSS APPLYno requiere un UDF como la tabla correcta.

En la mayoría de las INNER JOINconsultas (relaciones uno a muchos), podría reescribirlas para usarlas CROSS APPLY, pero siempre me dan planes de ejecución equivalentes.

¿Alguien puede darme un buen ejemplo de cuándo CROSS APPLYmarca la diferencia en aquellos casos en INNER JOINque funcionará también?

Editar:

Aquí hay un ejemplo trivial, donde los planes de ejecución son exactamente los mismos. (Muéstrame uno donde difieren y donde cross applyes más rápido / más eficiente)

create table Company (
    companyId int identity(1,1)
,   companyName varchar(100)
,   zipcode varchar(10) 
,   constraint PK_Company primary key (companyId)
)
GO

create table Person (
    personId int identity(1,1)
,   personName varchar(100)
,   companyId int
,   constraint FK_Person_CompanyId foreign key (companyId) references dbo.Company(companyId)
,   constraint PK_Person primary key (personId)
)
GO

insert Company
select 'ABC Company', '19808' union
select 'XYZ Company', '08534' union
select '123 Company', '10016'


insert Person
select 'Alan', 1 union
select 'Bobby', 1 union
select 'Chris', 1 union
select 'Xavier', 2 union
select 'Yoshi', 2 union
select 'Zambrano', 2 union
select 'Player 1', 3 union
select 'Player 2', 3 union
select 'Player 3', 3 


/* using CROSS APPLY */
select *
from Person p
cross apply (
    select *
    from Company c
    where p.companyid = c.companyId
) Czip

/* the equivalent query using INNER JOIN */
select *
from Person p
inner join Company c on p.companyid = c.companyId

¿Alguien puede darme un buen ejemplo de cuándo CROSS APPLY marca la diferencia en aquellos casos en que INNER JOIN también funcionará?

Vea el artículo en mi blog para una comparación detallada del rendimiento:

• INNER JOIN vs. CROSS APPLY

CROSS APPLYfunciona mejor en cosas que no tienen una JOINcondición simple .

Éste selecciona los 3últimos registros de t2cada registro de t1:

SELECT  t1.*, t2o.*
FROM    t1
CROSS APPLY
        (
        SELECT  TOP 3 *
        FROM    t2
        WHERE   t2.t1_id = t1.id
        ORDER BY
                t2.rank DESC
        ) t2o

No se puede formular fácilmente con una INNER JOINcondición.

Probablemente podría hacer algo así usando la función CTE's y ventana:

WITH    t2o AS
        (
        SELECT  t2.*, ROW_NUMBER() OVER (PARTITION BY t1_id ORDER BY rank) AS rn
        FROM    t2
        )
SELECT  t1.*, t2o.*
FROM    t1
INNER JOIN
        t2o
ON      t2o.t1_id = t1.id
        AND t2o.rn <= 3

, pero esto es menos legible y probablemente menos eficiente.

Actualizar:

Acabo de revisarlo.

masteres una tabla de 20,000,000registros con un PRIMARY KEYencendido id.

Esta consulta:

WITH    q AS
        (
        SELECT  *, ROW_NUMBER() OVER (ORDER BY id) AS rn
        FROM    master
        ),
        t AS 
        (
        SELECT  1 AS id
        UNION ALL
        SELECT  2
        )
SELECT  *
FROM    t
JOIN    q
ON      q.rn <= t.id

corre por casi 30segundos, mientras que este:

WITH    t AS 
        (
        SELECT  1 AS id
        UNION ALL
        SELECT  2
        )
SELECT  *
FROM    t
CROSS APPLY
        (
        SELECT  TOP (t.id) m.*
        FROM    master m
        ORDER BY
                id
        ) q

es instantáneo

cross applya veces te permite hacer cosas con las que no puedes hacer inner join.

Ejemplo (un error de sintaxis):

select F.* from sys.objects O  
inner join dbo.myTableFun(O.name) F   
on F.schema_id= O.schema_id

Este es un error de sintaxis porque, cuando se usa con inner join, las funciones de tabla solo pueden tomar variables o constantes como parámetros. (Es decir, el parámetro de la función de tabla no puede depender de la columna de otra tabla).

Sin embargo:

select F.* from sys.objects O  
cross apply ( select * from dbo.myTableFun(O.name) ) F  
where F.schema_id= O.schema_id

Esto es legal

Editar: O, alternativamente, sintaxis más corta: (por ErikE)

select F.* from sys.objects O  
cross apply dbo.myTableFun(O.name) F
where F.schema_id= O.schema_id

Editar:

Nota: Informix 12.10 xC2 + tiene tablas derivadas laterales y Postgresql (9.3+) tiene subconsultas laterales que se pueden usar con un efecto similar.

Considera que tienes dos mesas.

MESA PRINCIPAL

x------x--------------------x
| Id   |        Name        |
x------x--------------------x
|  1   |          A         |
|  2   |          B         |
|  3   |          C         |
x------x--------------------x

TABLA DE DETALLES

x------x--------------------x-------x
| Id   |      PERIOD        |   QTY |
x------x--------------------x-------x
|  1   |   2014-01-13       |   10  |
|  1   |   2014-01-11       |   15  |
|  1   |   2014-01-12       |   20  |
|  2   |   2014-01-06       |   30  |
|  2   |   2014-01-08       |   40  |
x------x--------------------x-------x

Hay muchas situaciones en las que debemos reemplazar INNER JOINconCROSS APPLY .

1. Unir dos tablas basadas en TOP n resultados.

Considere si necesitamos seleccionar Idy Namedesde Mastery las dos últimas fechas para cada uno Idde Details table.

SELECT M.ID,M.NAME,D.PERIOD,D.QTY
FROM MASTER M
INNER JOIN
(
    SELECT TOP 2 ID, PERIOD,QTY 
    FROM DETAILS D      
    ORDER BY CAST(PERIOD AS DATE)DESC
)D
ON M.ID=D.ID

• FIDDLE SQL

La consulta anterior genera el siguiente resultado.

x------x---------x--------------x-------x
|  Id  |   Name  |   PERIOD     |  QTY  |
x------x---------x--------------x-------x
|   1  |   A     | 2014-01-13   |  10   |
|   1  |   A     | 2014-01-12   |  20   |
x------x---------x--------------x-------x

Vea, generó resultados para las últimas dos fechas con las últimas dos fechas Idy luego unió estos registros solo en la consulta externa Id, lo cual es incorrecto. Esto debería devolver tanto Ids1 como 2, pero solo devolvió 1 porque 1 tiene las dos últimas fechas. Para lograr esto, necesitamos usar CROSS APPLY.

SELECT M.ID,M.NAME,D.PERIOD,D.QTY
FROM MASTER M
CROSS APPLY
(
    SELECT TOP 2 ID, PERIOD,QTY 
    FROM DETAILS D  
    WHERE M.ID=D.ID
    ORDER BY CAST(PERIOD AS DATE)DESC
)D

• FIDDLE SQL

y forma el siguiente resultado.

x------x---------x--------------x-------x
|  Id  |   Name  |   PERIOD     |  QTY  |
x------x---------x--------------x-------x
|   1  |   A     | 2014-01-13   |  10   |
|   1  |   A     | 2014-01-12   |  20   |
|   2  |   B     | 2014-01-08   |  40   |
|   2  |   B     | 2014-01-06   |  30   |
x------x---------x--------------x-------x

Así es como funciona. La consulta interna CROSS APPLYpuede hacer referencia a la tabla externa, donde INNER JOINno puede hacer esto (arroja un error de compilación). Al encontrar las dos últimas fechas, la unión se realiza dentro CROSS APPLY, es decir,WHERE M.ID=D.ID .

2. Cuando necesitamos INNER JOINfuncionalidad usando funciones.

CROSS APPLYse puede usar como un reemplazo INNER JOINcuando necesitamos obtener resultados de la Mastertabla y a function.

SELECT M.ID,M.NAME,C.PERIOD,C.QTY
FROM MASTER M
CROSS APPLY dbo.FnGetQty(M.ID) C

Y aquí está la función.

CREATE FUNCTION FnGetQty 
(   
    @Id INT 
)
RETURNS TABLE 
AS
RETURN 
(
    SELECT ID,PERIOD,QTY 
    FROM DETAILS
    WHERE ID=@Id
)

• FIDDLE SQL

que generó el siguiente resultado

x------x---------x--------------x-------x
|  Id  |   Name  |   PERIOD     |  QTY  |
x------x---------x--------------x-------x
|   1  |   A     | 2014-01-13   |  10   |
|   1  |   A     | 2014-01-11   |  15   |
|   1  |   A     | 2014-01-12   |  20   |
|   2  |   B     | 2014-01-06   |  30   |
|   2  |   B     | 2014-01-08   |  40   |
x------x---------x--------------x-------x

VENTAJA ADICIONAL DE APLICACIÓN CRUZADA

APPLYse puede usar como reemplazo de UNPIVOT. Ya seaCROSS APPLY o OUTER APPLYpuede usarse aquí, que son intercambiables.

Considere que tiene la siguiente tabla (nombrada MYTABLE).

x------x-------------x--------------x
|  Id  |   FROMDATE  |   TODATE     |
x------x-------------x--------------x
|   1  |  2014-01-11 | 2014-01-13   | 
|   1  |  2014-02-23 | 2014-02-27   | 
|   2  |  2014-05-06 | 2014-05-30   | 
|   3  |     NULL    |    NULL      |
x------x-------------x--------------x

La consulta está abajo.

SELECT DISTINCT ID,DATES
FROM MYTABLE 
CROSS APPLY(VALUES (FROMDATE),(TODATE))
COLUMNNAMES(DATES)

• FIDDLE SQL

que te trae el resultado

  x------x-------------x
  | Id   |    DATES    |
  x------x-------------x
  |  1   |  2014-01-11 |
  |  1   |  2014-01-13 |
  |  1   |  2014-02-23 |
  |  1   |  2014-02-27 |
  |  2   |  2014-05-06 |
  |  2   |  2014-05-30 | 
  |  3   |    NULL     | 
  x------x-------------x

Me parece que CROSS APPLY puede llenar un cierto vacío cuando se trabaja con campos calculados en consultas complejas / anidadas, y hacerlos más simples y legibles.

Ejemplo simple: tiene un DoB y desea presentar múltiples campos relacionados con la edad que también dependerán de otras fuentes de datos (como el empleo), como Age, AgeGroup, AgeAtHiring, MinimumRetirementDate, etc. para usar en su aplicación de usuario final (Tablas dinámicas de Excel, por ejemplo).

Las opciones son limitadas y rara vez elegantes:

• Las subconsultas JOIN no pueden introducir nuevos valores en el conjunto de datos en función de los datos de la consulta principal (debe ser independiente).

• Los UDF son limpios, pero lentos, ya que tienden a evitar operaciones paralelas. Y ser una entidad separada puede ser algo bueno (menos código) o malo (dónde está el código).

• Mesas de unión. A veces pueden funcionar, pero pronto te unes a subconsultas con toneladas de UNION. Gran desorden.

• Cree otra vista de un solo propósito, suponiendo que sus cálculos no requieren datos obtenidos a mitad de su consulta principal.

• Mesas intermedias. Sí ... eso generalmente funciona, y a menudo es una buena opción, ya que pueden indexarse ​​y ser rápidos, pero el rendimiento también puede disminuir debido a que las declaraciones de ACTUALIZACIÓN no son paralelas y no permiten que las fórmulas en cascada (reutilizar resultados) actualicen varios campos dentro del misma declaración Y a veces prefieres hacer las cosas de una sola vez.

• Consultas de anidamiento. Sí, en cualquier momento puede poner paréntesis en toda su consulta y usarlo como una subconsulta sobre la cual puede manipular los datos de origen y los campos calculados por igual. Pero solo puedes hacer esto mucho antes de que se ponga feo. Muy feo.

• Repetir código. ¿Cuál es el mayor valor de 3 declaraciones largas (CASE ... ELSE ... END)? ¡Eso será legible!

  • Dile a tus clientes que calculen las malditas cosas ellos mismos.

¿Me he perdido algo? Probablemente, así que siéntete libre de comentar. Pero bueno, CROSS APPLY es como un regalo del cielo en tales situaciones: solo agregas un simpleCROSS APPLY (select tbl.value + 1 as someFormula) as crossTbl y listo! Su nuevo campo ahora está listo para usar prácticamente como siempre había estado allí en sus datos de origen.

Los valores introducidos a través de CROSS APPLY pueden ...

• se puede usar para crear uno o varios campos calculados sin agregar problemas de rendimiento, complejidad o legibilidad a la mezcla
• Al igual que con JOIN, varias declaraciones CROSS APPLY posteriores pueden referirse a sí mismas: CROSS APPLY (select crossTbl.someFormula + 1 as someMoreFormula) as crossTbl2
• puede usar valores introducidos por una APLICACIÓN CRUZADA en condiciones subsiguientes de JOIN
• Como beneficio adicional, está el aspecto de función con valores de tabla

¡Dang, no hay nada que no puedan hacer!

La aplicación cruzada también funciona bien con un campo XML. Si desea seleccionar valores de nodo en combinación con otros campos.

Por ejemplo, si tiene una tabla que contiene algunos xml

<root>
    <subnode1>
       <some_node value="1" />
       <some_node value="2" />
       <some_node value="3" />
       <some_node value="4" />
    </subnode1>
</root>

Usando la consulta

SELECT
       id as [xt_id]
      ,xmlfield.value('(/root/@attribute)[1]', 'varchar(50)') root_attribute_value
  ,node_attribute_value = [some_node].value('@value', 'int')
  ,lt.lt_name   
FROM dbo.table_with_xml xt
CROSS APPLY xmlfield.nodes('/root/subnode1/some_node') as g ([some_node])
LEFT OUTER JOIN dbo.lookup_table lt
ON [some_node].value('@value', 'int') = lt.lt_id

Devolverá un resultado

xt_id root_attribute_value node_attribute_value lt_name
----------------------------------------------------------------------
1     test1            1                    Benefits
1     test1            4                    FINRPTCOMPANY

Esto ya se ha respondido muy bien técnicamente, pero permítanme dar un ejemplo concreto de cómo es extremadamente útil:

Digamos que tiene dos tablas, Cliente y Pedido. Los clientes tienen muchos pedidos.

Quiero crear una vista que me brinde detalles sobre los clientes y el pedido más reciente que han realizado. Con solo JOINS, esto requeriría algunas autouniones y agregaciones que no son bonitas. Pero con Cross Apply, es súper fácil:

SELECT *
FROM Customer
CROSS APPLY (
  SELECT TOP 1 *
  FROM Order
  WHERE Order.CustomerId = Customer.CustomerId
  ORDER BY OrderDate DESC
) T

La aplicación cruzada se puede utilizar para reemplazar las subconsultas donde necesita una columna de la subconsulta

subconsulta

select * from person p where
p.companyId in(select c.companyId from company c where c.companyname like '%yyy%')

aquí no podré seleccionar las columnas de la tabla de la compañía, así que, usando la aplicación cruzada

select P.*,T.CompanyName
from Person p
cross apply (
    select *
    from Company C
    where p.companyid = c.companyId and c.CompanyName like '%yyy%'
) T

Supongo que debería ser legibilidad;)

CROSS APPLY será algo único para las personas que leen y les digan que se está utilizando un UDF que se aplicará a cada fila de la tabla de la izquierda.

Por supuesto, hay otras limitaciones en las que una APLICACIÓN CRUZADA se usa mejor que ÚNETE que otros amigos han publicado anteriormente.

Aquí hay un artículo que lo explica todo, con su diferencia de rendimiento y uso sobre JOINS.

SQL Server CROSS APPLY y OUTER APPLY over JOINS

Como se sugiere en este artículo, no hay diferencia de rendimiento entre ellos para las operaciones de unión normales (INTERIOR Y CRUZ).

La diferencia de uso llega cuando tienes que hacer una consulta como esta:

CREATE FUNCTION dbo.fn_GetAllEmployeeOfADepartment(@DeptID AS INT)  
RETURNS TABLE 
AS 
RETURN 
   ( 
   SELECT * FROM Employee E 
   WHERE E.DepartmentID = @DeptID 
   ) 
GO 
SELECT * FROM Department D 
CROSS APPLY dbo.fn_GetAllEmployeeOfADepartment(D.DepartmentID)

Es decir, cuando tienes que relacionarte con la función. Esto no se puede hacer utilizando INNER JOIN, que le daría el error "El identificador de varias partes" D.DepartmentID "no se pudo vincular". Aquí el valor se pasa a la función a medida que se lee cada fila. A mí me parece genial. :)

Bueno, no estoy seguro de si esto califica como una razón para usar Cross Apply versus Inner Join, pero esta consulta fue respondida por mí en una publicación del foro usando Cross Apply, por lo que no estoy seguro de si hay un método igual usando Inner Join:

Create PROCEDURE [dbo].[Message_FindHighestMatches]

-- Declare the Topical Neighborhood
@TopicalNeighborhood nchar(255)

COMO COMIENZA

-- SET NOCOUNT ON added to prevent extra result sets from
-- interfering with SELECT statements.
SET NOCOUNT ON

Create table  #temp
(
    MessageID         int,
    Subjects          nchar(255),
    SubjectsCount    int
)

Insert into #temp Select MessageID, Subjects, SubjectsCount From Message

Select Top 20 MessageID, Subjects, SubjectsCount,
    (t.cnt * 100)/t3.inputvalues as MatchPercentage

From #temp 

cross apply (select count(*) as cnt from dbo.Split(Subjects,',') as t1
             join dbo.Split(@TopicalNeighborhood,',') as t2
             on t1.value = t2.value) as t
cross apply (select count(*) as inputValues from dbo.Split(@TopicalNeighborhood,',')) as t3

Order By MatchPercentage desc

drop table #temp

FINAL

La esencia del operador APLICAR es permitir la correlación entre el lado izquierdo y derecho del operador en la cláusula FROM.

A diferencia de JOIN, la correlación entre entradas no está permitida.

Hablando de correlación en el operador APLICAR, quiero decir en el lado derecho podemos poner:

• una tabla derivada - como una subconsulta correlacionada con un alias
• una función con valores de tabla: una vista conceptual con parámetros, donde el parámetro puede referirse al lado izquierdo

Ambos pueden devolver múltiples columnas y filas.

Esta es quizás una vieja pregunta, pero todavía me encanta el poder de CROSS APPLY para simplificar la reutilización de la lógica y proporcionar un mecanismo de "encadenamiento" para obtener resultados.

A continuación, proporcioné un Fiddle de SQL que muestra un ejemplo simple de cómo puede usar CROSS APPLY para realizar operaciones lógicas complejas en su conjunto de datos sin que las cosas se vuelvan desordenadas. No es difícil extrapolar desde aquí cálculos más complejos.

http://sqlfiddle.com/#!3/23862/2

Si bien la mayoría de las consultas que emplean CROSS APPLY pueden reescribirse usando INNER JOIN, CROSS APPLY puede generar un mejor plan de ejecución y un mejor rendimiento, ya que puede limitar el conjunto que se está uniendo antes de que se produzca la unión.

Robado de aquí