Pregunta sobre Union all en Vista

Carlos,

Esto puede ser una implementacion de vista particionada. Si cada tabla usa
restriccion de chequeo por la columna [col1] para serciorarse de que cada
tabla contiene valores independientes, y ademas tienes restriccion de clave
primaria apropiada, entonces SQL Server buscara en la tabla adecuada segun el
valor con que se filtra.

Using Partitioned Views
http://msdn.microsoft.com/en-us/lib...90019.aspx

A partir de la version 2005, SQL Server consta con la facilidad de tablas
particionadas, y desde la version 2008 se pueden crear vistas indexadas que
esten alineadas con la particion de la tabla. Tambien SQL Server 2008 hace
uso de multiprocesadores en caso de que se necesite tocar mas de una
particion para satisfacer un query.

Improving Performance with SQL Server 2008 Indexed Views
http://msdn.microsoft.com/en-us/lib...71921.aspx

Introduction to New Data Warehouse Scalability Features in SQL Server 2008
http://msdn.microsoft.com/en-us/lib...78097.aspx


AMB



"Carlos" wrote:

yo encuentro una base de datos que tiene una definicion de una vista
parecida a esto:

Create view LaVista as
select col1, col2, .
from tabla1 inner join tabla2 on ...
UNION ALL
select col1, col2, .
from tabla3 inner join tabla4 on ...

Sin ningun where .


mi duda o inquietud es si cuando uno va a usar la vista con una consulta con
un where como esta:

select col1, col2, ...
from LaVista where col1= 45

la consulta se optimiza bien con los indices que tengan tabla1 y tabla3
soble la col1.?

imagino que no es que primero hace la union y despues aplica el where? es
asi, no? espero:)

Hola tocayo,

On 7 jan, 20:49, "Carlos" <carl> wrote:

yo encuentro una base de datos que tiene una definicion de una vista
parecida a esto:

Create view LaVista as
select col1, col2, .
from tabla1 inner join tabla2 on ...
UNION ALL
select col1, col2, .
from tabla3 inner join tabla4 on ...

Sin ningun where .

mi duda o inquietud es si cuando uno va a usar la vista con una consulta con
un where como esta:

select col1, col2, ...
from LaVista where col1= 45

la consulta se optimiza bien con los indices que tengan tabla1 y tabla3
soble la col1.?

imagino que no es que primero hace la union y despues aplica el where? es
asi, no? espero:)

select col1, col2, ...
from LaVista where col1= 45

es equivalente a

select col1, col2, ...
from (
select col1, col2, .
from tabla1 inner join tabla2 on ...
UNION ALL
select col1, col2, .
from tabla3 inner join tabla4 on ...
) as LaVista
where where col1= 45

que a su vez es equivalente a

select col1, col2, .
from tabla1 inner join tabla2 on ...
where where col1= 45
UNION ALL
select col1, col2, .
from tabla3 inner join tabla4 on ...
where where col1= 45

que a su vez es equivalente a

select col1, col2, .
from (select * from tabla1 where col1E) as tabla1
inner join tabla2 on ...
UNION ALL
select col1, col2, .
from (select * from tabla3 where col1E) as tabla3
inner join tabla4 on ...

Como ves no hay que evaluar la union por completo para después
aplicar el where. Es mas, para evaluar los where ni hace falta
esperar a que se materialicen los joins (resultado del que
probablemente tendríamos que deshacernos casi por completo al
aplicar el where).

Lo más probable es que los where, los joins y la union funcionen
en paralelo y cada uno le vaya pasando resultados intermedios a
la operación siguiente. En ese orden (where->join->union), pero
sin necesidad de que una operación tenga que esperar a que el
resultado de la anterior esté completo, para ir ya haciendo su
trabajo.

Y siempre puedes consultar los planes de ejecución para todas
estas versiones y verás que son iguales o muy parecidos (pero
no lo he probado).

Saludos,
Carlos

Muchas gracias y que bueno que es asi que funciona.

Muchas gracias, me has dado informacion de mucho valor para lo que estoy
trabajando.


"Alejandro Mesa" escribió en el
mensaje news:

Carlos,

Esto puede ser una implementacion de vista particionada. Si cada tabla usa
restriccion de chequeo por la columna [col1] para serciorarse de que cada
tabla contiene valores independientes, y ademas tienes restriccion de
clave
primaria apropiada, entonces SQL Server buscara en la tabla adecuada segun
el
valor con que se filtra.

Using Partitioned Views
http://msdn.microsoft.com/en-us/lib...90019.aspx

A partir de la version 2005, SQL Server consta con la facilidad de tablas
particionadas, y desde la version 2008 se pueden crear vistas indexadas
que
esten alineadas con la particion de la tabla. Tambien SQL Server 2008 hace
uso de multiprocesadores en caso de que se necesite tocar mas de una
particion para satisfacer un query.

Improving Performance with SQL Server 2008 Indexed Views
http://msdn.microsoft.com/en-us/lib...71921.aspx

Introduction to New Data Warehouse Scalability Features in SQL Server 2008
http://msdn.microsoft.com/en-us/lib...78097.aspx


AMB



"Carlos" wrote:

yo encuentro una base de datos que tiene una definicion de una vista
parecida a esto:

Create view LaVista as
select col1, col2, .
from tabla1 inner join tabla2 on ...
UNION ALL
select col1, col2, .
from tabla3 inner join tabla4 on ...

Sin ningun where .


mi duda o inquietud es si cuando uno va a usar la vista con una consulta
con
un where como esta:

select col1, col2, ...
from LaVista where col1= 45

la consulta se optimiza bien con los indices que tengan tabla1 y tabla3
soble la col1.?

imagino que no es que primero hace la union y despues aplica el where? es
asi, no? espero:)