Consejos para realizar SELECT

Hola:
Hasta donde se:
a) Condicion de Filtro y de Join: En MS SQL no es necesario.
b) Condiciones IN (SELECT ...), en MS SQL es mejor idea, pero en la
mayoria de los casos el optimizador puede resolverlo y "standandariza" la
consulta.
c) Columnas como argumentos de funciones. SIP, en MS SQL si usas las
columnas como parametro de una funcion terminas con un Table Scan. :(
d) El operador LIKE no usa indices cuando es empleado como LIKE
'%algo%', pero normalmente si usa indices cuando es LIKE 'algo%'
e) Condicion NOT, en general si desactiva el uso del indice en MS SQL.
f) La condicion DISTINCT, efectivamente es ordenada, pero no
necesariamente los resultados se enviaran de forma ordenada. Si los
necesitas ordenados usa el ORDER BY. Muy importante en conjuntos grandes de
datos.
g) SELECT COUNT(*), funciona muy bien en MS SQL y permite que el
servidor use cualquier columna por lo que es el mas eficiente. En este caso
el * se traduce como cualquiera y no como todas.
Saludos,

Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda

"Claudio Valdés" wrote in message
news:

Estimados:

Encontre estos consejos para realizar consultas SELECT, pero son para

ORACLE

alguién me puede indicar si son igual de validos en SQL Server 2000
· Las condiciones (tanto de filtro como de join) deben ir siempre en el
orden en que esté definido el

índice. Si no hubiese índice por las columnas utilizadas, se puede

estudiar

la posibilidad de añadirlo, ya

que tener índices de más sólo penaliza los tiempos de inserción,
actualización y borrado, pero no de

consulta.

· Evitar la condiciones IN ( SELECT.) sustituyéndolas por joins.

· Colocar la tabla que devuelve menor número de registros en el último

lugar

del FROM

· Si en la cláusula WHERE se utilizan campos indexados como argumentos de
funciones, el índice quedará

desactivado.

· El operador LIKE no desactiva índices.

· Una condición negada con el operador NOT desactiva los índices

· Una consulta cualificada con la cláusula DISTINTC debe ser ordenada por

el

servidor aunque no se

incluya la cláusula ORDER BY.

· Para escribir una condición de existencia no se hace un SELECT COUNT(*),
se hace un SELECT 1

Desde ya muchas gracias por sus comentarios

Atte,
Claudio Valdés M

Interesante informacion, sobre todo me a sorprendido lo del NOT, eso
significa que en el futuro sera mejor utilizar <> (diferente) ?

Saludos,

Antonio Ortiz Ramirez
asesor en sistemas
ant(a)aortiz.net
www.aortiz.net
www.progvisual.com



"Javier Loria" escribió en el mensaje
news:

Hola:
Hasta donde se:
a) Condicion de Filtro y de Join: En MS SQL no es necesario.
b) Condiciones IN (SELECT ...), en MS SQL es mejor idea, pero en la
mayoria de los casos el optimizador puede resolverlo y "standandariza" la
consulta.
c) Columnas como argumentos de funciones. SIP, en MS SQL si usas las
columnas como parametro de una funcion terminas con un Table Scan. :(
d) El operador LIKE no usa indices cuando es empleado como LIKE
'%algo%', pero normalmente si usa indices cuando es LIKE 'algo%'
e) Condicion NOT, en general si desactiva el uso del indice en MS SQL.
f) La condicion DISTINCT, efectivamente es ordenada, pero no
necesariamente los resultados se enviaran de forma ordenada. Si los
necesitas ordenados usa el ORDER BY. Muy importante en conjuntos grandes

de

datos.
g) SELECT COUNT(*), funciona muy bien en MS SQL y permite que el
servidor use cualquier columna por lo que es el mas eficiente. En este

caso

el * se traduce como cualquiera y no como todas.
Saludos,

Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda

"Claudio Valdés" wrote in message
news:
> Estimados:
>
> Encontre estos consejos para realizar consultas SELECT, pero son para
ORACLE
> alguién me puede indicar si son igual de validos en SQL Server 2000
> · Las condiciones (tanto de filtro como de join) deben ir siempre en el
> orden en que esté definido el
>
> índice. Si no hubiese índice por las columnas utilizadas, se puede
estudiar
> la posibilidad de añadirlo, ya
>
> que tener índices de más sólo penaliza los tiempos de inserción,
> actualización y borrado, pero no de
>
> consulta.
>
> · Evitar la condiciones IN ( SELECT.) sustituyéndolas por joins.
>
> · Colocar la tabla que devuelve menor número de registros en el último
lugar
> del FROM
>
> · Si en la cláusula WHERE se utilizan campos indexados como argumentos

de

> funciones, el índice quedará
>
> desactivado.
>
> · El operador LIKE no desactiva índices.
>
> · Una condición negada con el operador NOT desactiva los índices
>
> · Una consulta cualificada con la cláusula DISTINTC debe ser ordenada

por

el
> servidor aunque no se
>
> incluya la cláusula ORDER BY.
>
> · Para escribir una condición de existencia no se hace un SELECT

COUNT(*),

> se hace un SELECT 1
>
> Desde ya muchas gracias por sus comentarios
>
> Atte,
> Claudio Valdés M
>
>

Hola:
En estos momentos es mejor usar:
==WHERE Columna > 0 OR Columna < 0
== Lo cual no es muy bonito :(

Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda

"Antonio Ortiz" wrote in message
news:#

Interesante informacion, sobre todo me a sorprendido lo del NOT, eso
significa que en el futuro sera mejor utilizar <> (diferente) ?

Saludos,

Antonio Ortiz Ramirez
asesor en sistemas
ant(a)aortiz.net
www.aortiz.net
www.progvisual.com



"Javier Loria" escribió en el mensaje
news:
> Hola:
> Hasta donde se:
> a) Condicion de Filtro y de Join: En MS SQL no es necesario.
> b) Condiciones IN (SELECT ...), en MS SQL es mejor idea, pero en la
> mayoria de los casos el optimizador puede resolverlo y "standandariza"

la

> consulta.
> c) Columnas como argumentos de funciones. SIP, en MS SQL si usas las
> columnas como parametro de una funcion terminas con un Table Scan. :(
> d) El operador LIKE no usa indices cuando es empleado como LIKE
> '%algo%', pero normalmente si usa indices cuando es LIKE 'algo%'
> e) Condicion NOT, en general si desactiva el uso del indice en MS

SQL.

> f) La condicion DISTINCT, efectivamente es ordenada, pero no
> necesariamente los resultados se enviaran de forma ordenada. Si los
> necesitas ordenados usa el ORDER BY. Muy importante en conjuntos grandes
de
> datos.
> g) SELECT COUNT(*), funciona muy bien en MS SQL y permite que el
> servidor use cualquier columna por lo que es el mas eficiente. En este
caso
> el * se traduce como cualquiera y no como todas.
> Saludos,
>
> Javier Loria
> Costa Rica
> Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
> que pueda ser copiado y pegado al Query Analizer.
> La version de SQL y Service Pack tambien ayuda
>
> "Claudio Valdés" wrote in message
> news:
> > Estimados:
> >
> > Encontre estos consejos para realizar consultas SELECT, pero son para
> ORACLE
> > alguién me puede indicar si son igual de validos en SQL Server 2000
> > · Las condiciones (tanto de filtro como de join) deben ir siempre en

el

> > orden en que esté definido el
> >
> > índice. Si no hubiese índice por las columnas utilizadas, se puede
> estudiar
> > la posibilidad de añadirlo, ya
> >
> > que tener índices de más sólo penaliza los tiempos de inserción,
> > actualización y borrado, pero no de
> >
> > consulta.
> >
> > · Evitar la condiciones IN ( SELECT.) sustituyéndolas por joins.
> >
> > · Colocar la tabla que devuelve menor número de registros en el último
> lugar
> > del FROM
> >
> > · Si en la cláusula WHERE se utilizan campos indexados como argumentos
de
> > funciones, el índice quedará
> >
> > desactivado.
> >
> > · El operador LIKE no desactiva índices.
> >
> > · Una condición negada con el operador NOT desactiva los índices
> >
> > · Una consulta cualificada con la cláusula DISTINTC debe ser ordenada
por
> el
> > servidor aunque no se
> >
> > incluya la cláusula ORDER BY.
> >
> > · Para escribir una condición de existencia no se hace un SELECT
COUNT(*),
> > se hace un SELECT 1
> >
> > Desde ya muchas gracias por sus comentarios
> >
> > Atte,
> > Claudio Valdés M
> >
> >
>
>

Supongo que tendria que usar otro recurso cuando se trate de negar varias
condiciones del tipo

Not ( (Col1<>exp) or (Col2>exp) and (Col3=exp3))


Saludos,

Antonio Ortiz
Asesor en Sistemas
ant(a)aortiz.net
www.aortiz.net
www.progvisual.com




"Javier Loria" escribió en el mensaje
news:#

Hola:
En estos momentos es mejor usar:
==> WHERE Columna > 0 OR Columna < 0
==> Lo cual no es muy bonito :(

Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda

"Antonio Ortiz" wrote in message
news:#
> Interesante informacion, sobre todo me a sorprendido lo del NOT, eso
> significa que en el futuro sera mejor utilizar <> (diferente) ?
>
> Saludos,
>
> Antonio Ortiz Ramirez
> asesor en sistemas
> ant(a)aortiz.net
> www.aortiz.net
> www.progvisual.com
>
>
>
> "Javier Loria" escribió en el mensaje
> news:
> > Hola:
> > Hasta donde se:
> > a) Condicion de Filtro y de Join: En MS SQL no es necesario.
> > b) Condiciones IN (SELECT ...), en MS SQL es mejor idea, pero en

la

> > mayoria de los casos el optimizador puede resolverlo y "standandariza"
la
> > consulta.
> > c) Columnas como argumentos de funciones. SIP, en MS SQL si usas

las

> > columnas como parametro de una funcion terminas con un Table Scan. :(
> > d) El operador LIKE no usa indices cuando es empleado como LIKE
> > '%algo%', pero normalmente si usa indices cuando es LIKE 'algo%'
> > e) Condicion NOT, en general si desactiva el uso del indice en MS
SQL.
> > f) La condicion DISTINCT, efectivamente es ordenada, pero no
> > necesariamente los resultados se enviaran de forma ordenada. Si los
> > necesitas ordenados usa el ORDER BY. Muy importante en conjuntos

grandes

> de
> > datos.
> > g) SELECT COUNT(*), funciona muy bien en MS SQL y permite que el
> > servidor use cualquier columna por lo que es el mas eficiente. En este
> caso
> > el * se traduce como cualquiera y no como todas.
> > Saludos,
> >
> > Javier Loria
> > Costa Rica
> > Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
> > que pueda ser copiado y pegado al Query Analizer.
> > La version de SQL y Service Pack tambien ayuda
> >
> > "Claudio Valdés" wrote in message
> > news:
> > > Estimados:
> > >
> > > Encontre estos consejos para realizar consultas SELECT, pero son

para

> > ORACLE
> > > alguién me puede indicar si son igual de validos en SQL Server 2000
> > > · Las condiciones (tanto de filtro como de join) deben ir siempre en
el
> > > orden en que esté definido el
> > >
> > > índice. Si no hubiese índice por las columnas utilizadas, se puede
> > estudiar
> > > la posibilidad de añadirlo, ya
> > >
> > > que tener índices de más sólo penaliza los tiempos de inserción,
> > > actualización y borrado, pero no de
> > >
> > > consulta.
> > >
> > > · Evitar la condiciones IN ( SELECT.) sustituyéndolas por joins.
> > >
> > > · Colocar la tabla que devuelve menor número de registros en el

último

> > lugar
> > > del FROM
> > >
> > > · Si en la cláusula WHERE se utilizan campos indexados como

argumentos

> de
> > > funciones, el índice quedará
> > >
> > > desactivado.
> > >
> > > · El operador LIKE no desactiva índices.
> > >
> > > · Una condición negada con el operador NOT desactiva los índices
> > >
> > > · Una consulta cualificada con la cláusula DISTINTC debe ser

ordenada

> por
> > el
> > > servidor aunque no se
> > >
> > > incluya la cláusula ORDER BY.
> > >
> > > · Para escribir una condición de existencia no se hace un SELECT
> COUNT(*),
> > > se hace un SELECT 1
> > >
> > > Desde ya muchas gracias por sus comentarios
> > >
> > > Atte,
> > > Claudio Valdés M
> > >
> > >
> >
> >
>
>