Indice en columna tipo bit

Yo suelo usar smallint.
La razón es sencilla: no todas las BD tienen el tipo lógico, o bit (es decir
un tipo que acepte sólo dos valores).

Si planeás una migración (o que tu aplicación corra sobre varias bd)
entonces si usás tipo bit vas a tener que hacer conversiones al migrar.
En cuanto al índice por el campo bit, francamente no veo que se pueda
hacer(da error). Smallint sí te lo permite.





"Berta Gomez" wrote:

Veo que al querer crear un indice en una columna tipo bit no me lo permite.
Sin embargo tengo consultas que hacen uso frecuente de una columna tipo bit
y estoy pensando poner un indice para tratar de agilizarla.

Que deberia hacer ? no usar el tipo bit sino convertirlo a un tinyint ?

que me recomiendan?

Hola, hablando del tipo de dato ;), has probado en usar en tus sistemas
Char(1) y solo admitir Y/N?

Te lo recomiendo ;)


Salu2
Maxi


"Asterion" escribió en el mensaje
news:

Yo suelo usar smallint.
La razón es sencilla: no todas las BD tienen el tipo lógico, o bit (es
decir
un tipo que acepte sólo dos valores).

Si planeás una migración (o que tu aplicación corra sobre varias bd)
entonces si usás tipo bit vas a tener que hacer conversiones al migrar.
En cuanto al índice por el campo bit, francamente no veo que se pueda
hacer(da error). Smallint sí te lo permite.





"Berta Gomez" wrote:

Veo que al querer crear un indice en una columna tipo bit no me lo
permite.
Sin embargo tengo consultas que hacen uso frecuente de una columna tipo
bit
y estoy pensando poner un indice para tratar de agilizarla.

Que deberia hacer ? no usar el tipo bit sino convertirlo a un tinyint ?

que me recomiendan?

Sí, es más rápido.

Pero en particular a mí no me sirve.
Yo trabajo mucho con sistemas que se usan en bases de datos de distinto
tipo(Oracle, Informix, DB2, etc).
En la mayoría de ellas (sobre todo en las versiones de 4 años para atrás) el
campo lógico se almacena como 0 ó 1. Por compatibilidad entonces se suele
usar esa representación, aunque no es la mejor.

Gracias por la recomendación, que es buena.

Hola, justamente por eso te lo decia ;) yo tambien trabajo y migre de varios
motores y lo que siempre me funciono fue poner char(1) y solo adminitir S/N,
en otras palabras, me arme el tipo de datos logico, porque? porque entre
motores difiere la logica, algunos usan -1, 0 y otros 0, 1, entonces al usar
ahora campos char(1) y mis aplicaciones consultar eso cuando migro me olvido
de este dolor de cabezas que una vez me paso :-)


Salu2
Maxi


"Asterion" escribió en el mensaje
news:

Sí, es más rápido.

Pero en particular a mí no me sirve.
Yo trabajo mucho con sistemas que se usan en bases de datos de distinto
tipo(Oracle, Informix, DB2, etc).
En la mayoría de ellas (sobre todo en las versiones de 4 años para atrás)
el
campo lógico se almacena como 0 ó 1. Por compatibilidad entonces se suele
usar esa representación, aunque no es la mejor.

Gracias por la recomendación, que es buena.

Hola Asterion,

estoy de acuerdo con el razonamiento de que es más facil migrar a otros
sistemas de bases de datos una columna tipo char, smallint, etc. que bit,
pero no estoy de acuerdo con que es más rápido una columna tipo char(1) que
permite dos valores que una de tipo bit; si es como tu dices, es totalmente
novedoso para mí porque nunca he hecho ningún analisis de rendimiento
analizando bit frente a char(1) con dos valores.

Mi razonamiento es que una columna tipo char(1) ocupa un byte, y una columna
tipo bit (solo una en toda la tabla) ocupa también un byte; por lo tanto
serían ambos igual de eficientes; sin embargo si a la tabla añades una
columna más (un char(1) por un lado y un bit en el otro), en un caso usará 1
byte más (el espacio de char(1)), mientras que en el tipo bit usaría parte
del byte usado en la columna bit anterior; por lo tanto como ocupa menos,
más filas habrá por página y más filas se leerán de cada página.

Saludos,

Eladio Rincón
SQL Server MVP

Solid Quality Learning (http://www.solidqualitylearning.com)
"Comparte lo que sabes, aprende lo que no sepas", FGG

Consulte el histórico del grupo en Google
http://groups.google.com/groups?gro....sqlserver

¿Te interesa participar en las reuniones
del grupo de Usuarios de SQL-Server y .NET
Se harán en levante de España, (Alicante o Murcia)?

"Asterion" wrote in message
news:

Sí, es más rápido.

Pero en particular a mí no me sirve.
Yo trabajo mucho con sistemas que se usan en bases de datos de distinto
tipo(Oracle, Informix, DB2, etc).
En la mayoría de ellas (sobre todo en las versiones de 4 años para atrás)

el

campo lógico se almacena como 0 ó 1. Por compatibilidad entonces se suele
usar esa representación, aunque no es la mejor.

Gracias por la recomendación, que es buena.