indice en campo BIT

En la mayoría de los casos, crear un índice en los que hay muy poca
variación de los valores que puede contener (en este caso sólo 0 ó 1) no
tiene mucho sentido. Ahora bien, si la distribución de esos valores es muy
diferente igual sí te podría interesar; es decir, si tienes 100.000
registros y sólo 10 de ellos tienen el valor 0, entonces sí tendría sentido.
Si por el contrario hay una distribución próxima al 50%, un índice en ese
campo no será efectivo


Un saludo

-
"Sólo sé que no sé nada. " (Sócrates)

"Gaston P" escribió en el mensaje
news:

Buen dia,

tengo una tabla con alrededor de 300.000 registros
uno de estos campos es bit.

el 99% de las consultas me tienen que traer los registros en que este

campo

bit, esté en 0.

tendré que realizar un indice sobre este campo?

Los campos Bit no se pueden indexar, por tanto tendras que cambiar el tipo
de dato a un entero como 'smallint' o 'int'


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


"Gaston P" escribió en el mensaje
news:

Buen dia,

tengo una tabla con alrededor de 300.000 registros
uno de estos campos es bit.

el 99% de las consultas me tienen que traer los registros en que este
campo bit, esté en 0.

tendré que realizar un indice sobre este campo?

Antonio,

Al menos en la version 2000 si se permite.

create table t1 (
c1 bit not null
)
go

create nonclustered index t1_c1_nu_nc_idx on t1(c1)
go

drop table t1
go


AMB


"Antonio Ortiz" wrote:

Los campos Bit no se pueden indexar, por tanto tendras que cambiar el tipo
de dato a un entero como 'smallint' o 'int'


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


"Gaston P" escribió en el mensaje
news:
> Buen dia,
>
> tengo una tabla con alrededor de 300.000 registros
> uno de estos campos es bit.
>
> el 99% de las consultas me tienen que traer los registros en que este
> campo bit, esté en 0.
>
> tendré que realizar un indice sobre este campo?
>
>

mm, por ahi lei que no, esto despues de no encontrar como indexar un campo
bit a traves del Enterprise Manager, donde ni siquiere aparecen los campos
tipo Bit.

Gracias por por aclararlo, lo que indicas lo he probado y confirma lo dicho
por ti.

saludos,


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


"Alejandro Mesa" escribió en el
mensaje news:

Antonio,

Al menos en la version 2000 si se permite.

create table t1 (
c1 bit not null
)
go

create nonclustered index t1_c1_nu_nc_idx on t1(c1)
go

drop table t1
go


AMB


"Antonio Ortiz" wrote:

Los campos Bit no se pueden indexar, por tanto tendras que cambiar el
tipo
de dato a un entero como 'smallint' o 'int'


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


"Gaston P" escribió en el mensaje
news:
> Buen dia,
>
> tengo una tabla con alrededor de 300.000 registros
> uno de estos campos es bit.
>
> el 99% de las consultas me tienen que traer los registros en que este
> campo bit, esté en 0.
>
> tendré que realizar un indice sobre este campo?
>
>

Hola.

Voy a tratar de aportar algo más a lo dicho por los compañeros.

Un índice en un campo bit (que sí que se puede hacer desde SQL Server 2000)
y sólo por el campo de tipo bit, no creo que sea muy práctico. Sin embargo,
acompañado de algún campo más que tengas en el filtro, puede ser de gran
utilidad. Supongamos el caso típico, tienes un campo de estado en tu tabla,
de tipo bit, que diferencia los clientes activos (estado = 1) de los
inactivos (estado=0). Tus consultas serán variopintas, pero llevarán casi
siempre la coletilla ...and estado = 1. En ese caso, tus índices pueden ir
perfectamente con el campo estado incluido, incluso, en primer lugar. Ten en
cuenta que es un valor fijado, al optimizador es lo que más le gusta. Y en
coste, pues realmente poco, ya que apenas ocupa espacio y un bit más no
variará mucho el número de registros por página. Un ejemplo:

Tu consulta:

Select IdCiente from Clientes where Apellidos like 'López Grande%' and
estado = 1

Tienes un índice por el campo Apellidos únicamente, para la query, se ha de
hacer un bookmark (muy rápido, no nos engañemos) para verificar el campo
estado

Sin embargo, en tu aplicación la consulta será más bien así:

Select IdCliente from Clientes where Apellidos like @par1 and estado = 1

Con lo que tener un índice por los campos estado (en mi caso, mejor en orden
descendiente) y apellidos algo mejor, no mucho mejor, pero sí algo mejor, ya
que el valor es fijo, lo cual da una pista más al optimizador de que el
índice que ha de usarse es el que tienes por el apellido (precedido del
estado).

No sé si te servirá de ayuda. Espero que sí.

Alberto López Grande (qwalgrande)


"Gaston P" escribió en el mensaje
news:

Buen dia,

tengo una tabla con alrededor de 300.000 registros
uno de estos campos es bit.

el 99% de las consultas me tienen que traer los registros en que este
campo bit, esté en 0.

tendré que realizar un indice sobre este campo?