Cual es la mejor manera de CONSTRUIR sentencias SELECT ?

30/09/2009 - 20:21 por Ernest | Informe spam

Hola amigos que tal como están ?

Tengo una consulta : Estoy comenzando en SQL SERVER y necesito saber cuál es
la mejor manera de construir las
sentencias SELECT.

Hasta el momento he trabajado mis consultas de la siguiente manera. (Usando
otras Bases de Datos) Ejemplo :

SELECT a.num_factura, a.fecha, a.cod_cliente, b.nom_cliente
FROM vta a, cliente b
WHERE a.cod_cliente = b.cod_cliente
AND &&&&& Todas las condiciones que quiero. etc.

Pero parece que en SQL SERVER debería de ser de éste modo :

SELECT a.num_factura, a.fecha, a.cod_cliente, b.nom_cliente
FROM vta a
INNER JOIN cliente b
ON a.cod_cliente = b.cod_cliente ;
WHERE &&&&& Todas las condiciones que quiero. etc.

La verdad, es que leí por allí que hacerlo de la primera forma
afecta el rendimiento.

Pero yo he trabajado en VFP 9.0 datos considerables y al contrario mis
queries han resultado más rápidos y eficientes
que los escritos usando el INNER JOIN que traía la aplicación por defaul.t
(Es una aplicación que se compró a terceros en la empresa donde laboro
construida en VFP 9.0).

Por eso, ahora que tengo que comenzar a trabajar en SQL SERVER me gustaría
saber, de acuerdo a su experiencia,
si en verdad afecta de manera sensible el rendimiento. Porque la verdad
considero mucho más fácil hacerlo
de la primera manera. La segunda me parece es Transact SQL.

No omito, comentarles que la aplicación que pienso hacer es pequeña por lo
que pienso utilizar la Versión Express
que soporta hasta 4 GB.

Les agradezco mucho su gran ayuda.

Siga el debate

18 respuestas

Tengo una respuesta

Preguntas similare

Mostrar todos los temas similares

Leer las respuestas

#16 aa

05/10/2009 - 18:52 | Informe spam

Si,es mas rapido.
"Carlos M. Calvelo" wrote in message
news:
Hola aa,

On 3 okt, 00:11, "aa" wrote:

El where si afecta ya que no es lo mismo hacer
select * from tabla a,table b
where a.campo1 = b.campo2 and
otras variables
and b.campo3 = 5

que hacer
select * from tabla a inner join table b
on a.campo1 = b.campo2 and b.campo3=5
where otras variables
ya que ahi el inner es mas rapido porque filtra antes.

Estás seguro?

Saludos,
Carlos

Responder a este mensaje

#17 Carlos M. Calvelo

05/10/2009 - 22:50 | Informe spam

Hola aa,

On 5 okt, 18:52, "aa" wrote:

Si,es mas rapido.

Y eso? Por qué?

select *
from tabla a,tabla b
where a.campo1 = b.campo2
and b.campo3=5
and <otras condiciones>

y

select *
from tabla a inner join tabla b
on a.campo1=b.campo2 and b.campo3=5
where <otras condiciones>

son lógicamente equivalentes.

Solo eso y el hecho de que es una equivalencia 'común' es suficiente
para poder predecir que con un optimizador medianamente decente,
después de una transformación sintáctica, las dos resultarán en la
misma forma intermedia, que es la que a su vez determina (junto con
otros mecanismos como índices, estadísticas, etc.) el plan de
ejecución.

En esa forma intermedia (independientemente de cual fuera la forma
original) las condiciones que solo dependen de una tabla (como
b.campo3=5) se evaluarán antes para reducir al máximo el número
de registros para los que hay que evaluar las condiciones del join.

(Pero me puedo equivocar.)

Saludos,
Carlos

Responder a este mensaje

#18 Carlos Sacristan

06/10/2009 - 09:22 | Informe spam

No encuentro sentido a la discusión. Como decía en un post anterior, lo suyo
es ver el plan de ejecución de una instrucción con INNER JOIN y otra con las
condiciones de combinación en el WHERE y ver si hay alguna diferencia.

Prueba a ejecutar el batch siguiente:

***************************************************************************************

USE AdventureWorks

GO

SET NOCOUNT ON

GO

SELECT p.name , sc.name
FROM Production.Product p
INNER JOIN Production.ProductSubcategory sc
ON p.ProductSubcategoryID = sc.ProductSubcategoryID
WHERE p.ProductID < 1000

GO

SELECT p.name , sc.name
FROM Production.Product p ,
Production.ProductSubcategory sc
WHERE p.ProductSubcategoryID = sc.ProductSubcategoryID
AND p.ProductID < 1000

***************************************************************************************

A mí el plan de ejecución (modo texto) me devuelve (sobre Microsoft SQL
Server 2008 (SP1) - 10.0.2531.0)

***************************************************************************************

StmtText

SELECT p.name , sc.name
FROM Production.Product p
INNER JOIN Production.ProductSubcategory sc
ON p.ProductSubcategoryID = sc.ProductSubcategoryID
WHERE p.ProductID < 1000

(1 row(s) affected)

StmtText

|--Hash Match(Inner Join,
HASH:([sc].[ProductSubcategoryID])=([p].[ProductSubcategoryID]),
RESIDUAL:([AdventureWorks].[Production].[ProductSubcategory].[ProductSubcategoryID]
as
[sc].[ProductSubcategoryID]=[AdventureWorks].[Production].[Product].[ProductSubcategoryID]
as [p].[ProductSubcategoryID]))
|--Index
Scan(OBJECT:([AdventureWorks].[Production].[ProductSubcategory].[AK_ProductSubcategory_Name]
AS [sc]))
|--Clustered Index
Seek(OBJECT:([AdventureWorks].[Production].[Product].[PK_Product_ProductID]
AS [p]), SEEK:([p].[ProductID] < (1000)) ORDERED FORWARD)

(3 row(s) affected)

StmtText
-

SELECT p.name , sc.name
FROM Production.Product p ,
Production.ProductSubcategory sc
WHERE p.ProductSubcategoryID = sc.ProductSubcategoryID
AND p.ProductID < 1000

(1 row(s) affected)

StmtText

|--Hash Match(Inner Join,
HASH:([sc].[ProductSubcategoryID])=([p].[ProductSubcategoryID]),
RESIDUAL:([AdventureWorks].[Production].[Product].[ProductSubcategoryID] as
[p].[ProductSubcategoryID]=[AdventureWorks].[Production].[ProductSubcategory].[ProductSubcategoryID]
as [sc].[ProductSubcategoryID]))
|--Index
Scan(OBJECT:([AdventureWorks].[Production].[ProductSubcategory].[AK_ProductSubcategory_Name]
AS [sc]))
|--Clustered Index
Seek(OBJECT:([AdventureWorks].[Production].[Product].[PK_Product_ProductID]
AS [p]), SEEK:([p].[ProductID] < (1000)) ORDERED FORWARD)

(3 row(s) affected)

***************************************************************************************

Yo diría que se parecen bastante, no?
"Caminar sobre el agua y desarrollar software a partir de unas
especificaciones es fácil, si ambas están congeladas."
Edward V. Berard, ingeniero informático

"aa" wrote in message
news:

Si,es mas rapido.
"Carlos M. Calvelo" wrote in message
news:
Hola aa,

On 3 okt, 00:11, "aa" wrote:

El where si afecta ya que no es lo mismo hacer
select * from tabla a,table b
where a.campo1 = b.campo2 and
otras variables
and b.campo3 = 5

que hacer
select * from tabla a inner join table b
on a.campo1 = b.campo2 and b.campo3=5
where otras variables
ya que ahi el inner es mas rapido porque filtra antes.

Estás seguro?

Saludos,
Carlos

Siga el debate Respuesta

Responder a este mensaje

Ads by Google

Hacer una pregunta

Tengo una respuesta

1 2 3 4

Busqueda sugerida