Campo bool o booleano en tabla de sql server

Hola Carlos,


"Carlos M. Calvelo" wrote:

En cuanto al razonamiento del idioma, tambien se puede tener '0' y '1'
(char) en vez de 0 y 1 (int). O 'T' / 'F'

Lo que me gusta de usar 0/1 por sobre '0'/'1' es que con las operaciones + y
* es muy simple simular las operaciones booleanas.

Y, last but no least, no se pueden definir índices con columnas tipo
BIT.

Buen punto, aunque dada la poca selectividad de las columnas de tipo
booleana, suelen participar poco en indizaciones.

En resumen, me gusta más una representación numérica para un dato booleano.
Es una preferencia personal simplemente.

Saludos,
Carlos

Saludos,
~gux

Hola Carlos,

"Carlos M. Calvelo" wrote:

Ah!
Y crear un User defined type 'Boolean' con una restricción (rule)
y usar ese tipo consecuentemente a la hora de definir las tablas.

Por ejemplo 'Boolean' basado en char(5) y con una restricción
@value IN ('true', 'false')

Los UDT no me agradan demasiado debido a que no permiten definir operaciones
sobre los valores del tipo. Por ejemplo, el AND, OR y NOT. En mi humilde
opinión, los UDT son una idea sin terminar :-)

En SQL Server 2005/2008 el poder definir tipos usando .NET es una mejora en
ese sentido. De todas formas no soy tampoco de definir tipos .NET para las
columnas, aunque tal vez para variables en los procedimientos.

Saludos,
Carlos

Saludos,
~gux

Hola Gustavo,

On 13 sep, 02:45, Gustavo Larriera (MVP)
wrote:

Lo que me gusta de usar 0/1 por sobre '0'/'1' es que con las operaciones + y
* es muy simple simular las operaciones booleanas.

Ten cuidado de no hacer algo como
IF campo1 + campo2 = 1
en vez de
IF campo1 + campo2 > 0
:-)

Pero... buena idea.

Saludos,
Carlos

Hola Gustavo,

On 13 sep, 02:56, Gustavo Larriera (MVP)
wrote:

Hola Carlos,

"Carlos M. Calvelo" wrote:
> Ah!
> Y crear un User defined type 'Boolean' con una restricción (rule)
> y usar ese tipo consecuentemente a la hora de definir las tablas.

> Por ejemplo 'Boolean' basado en char(5) y con una restricción
> @value IN ('true', 'false')

Los UDT no me agradan demasiado debido a que no permiten definir operaciones
sobre los valores del tipo. Por ejemplo, el AND, OR y NOT. En mi humilde
opinión, los UDT son una idea sin terminar :-)

:-)
Eso está claro. De 'tipos' no tienen nada. Son mas bien un alias de
tipos definidos por el sistema. Aun así, ofrecen la posibilidad de
especificar una restricción solo en un sitio en vez de en 100
columnas. O utilizando solo el nombre, se documenta que columnas en
distintas tablas son en realidad del mismo tipo (que tiene sentido
una comparacion de valores, por ejemplo.), aunque el tipo base sea
el mismo que en otras columnas que no tienen nada que ver.
Por ejemplo, decir que una columna es del tipo 'Temperatura' (INT)
nos dice que no tiene mucho sentido compararla con otra columna
del tipo Longitud (también INT)

En SQL Server 2005/2008 el poder definir tipos usando .NET es una mejora en
ese sentido. De todas formas no soy tampoco de definir tipos .NET para las
columnas, aunque tal vez para variables en los procedimientos.

Uff... ese ya es un tema que se las trae. Bueno... por ahí es por
donde tenían que ir los UDT. Imagínate tener tipos como XMLDoc,
BITMAP, WordDocument, TextDocument, Foto, Map, Sound, etc, etc.

Y poder definirlos tu con las mismas posibilidades (definir
operadores) y con el mismo nivel de integración en el lenguaje que
los 'system defined types'.

Por poner un ejemplo muy sencillo:
A menudo tenemos la situación de que tenemos que definir rangos.
Algo como FechaInicial y FechaFinal. En estos casos estas dos
columnas son interdependientes ( ini <= fin). O sea que no dependen
solo de la clave. Si lo piensas bien, estas dos columnas a nivel de
lo que estamos definiendo en la tabla son una unidad y convendría
tener un tipo como Periodo.

Imagínate ahora poder definir un tipo Periodo, con esos dos
componentes y, entre otras cosas, operadores como Overlaps()...

WHERE tabla1.per.Overlaps(tabla2.per)

.. You get the idea!

Las propuestas de Date y Darwen son excelentes en este sentido y
siguen trabajando en el tema. Hasta con un buen modelo de herencia
de tipos.

Saludos,
Carlos

Bueno son formas nomas, yo a los usuarios no les muestro ni 1 ni 0 ni S ni
N, asi que es indistinto :) o tu le muestras 1 o 0? o bien los usas como
desarrollador y los interpretas luego? si usas bit a la larga tambien lo
tiene que convertir en algo que el usuario interprete jaja

Pero bueno son formas nomas!


Saludos
Maxi Accotto
Microsoft MVP en SQLServer
SQltotalconsulting
-

"Gustavo Larriera (MVP)"
escribió en el mensaje de
noticias:

No comparto tu idea, querido amigo Maxi.

Usar 'S' o 'N' no es demasiado bueno. Imaginemos que la base es usada por
personas que hablen inglés por ejemplo... además de lidiar con la
sensibilidad de mayúsculas/minúsculas, además de tener que poner más
"inteligencia" en las aplicaciones para enteneder que 'S' es verdadero y
'N'
es falso.

Si no se quiere usar BIT por una cuestión de ser un tipo demasiado
propietario de SQL Server, entonces es preferible usar algún tipo integer
que
es un tipo de datos disponible en cualquier sistema.

Y luego almacenar con 0 (FALSE) y un valor no-cero para TRUE (prefiero 1),
siguiendo la idea clásica de C90.

Gustavo Larriera, Microsoft MVP
http://www.linkedin.com/in/gustavolarriera
Este mensaje se proporciona tal como es, sin garantías de ninguna clase.



"Maxi Accotto" wrote:

Hola, yo uso char(1) y pongo S o N.


Saludos
Maxi Accotto
Microsoft MVP en SQLServer
SQltotalconsulting
-

"Pedro" escribió en el mensaje de
noticias:
> Quiero un campo en una tabla que me represente un flag o valor bool
> (true
> o false). Cuales es la mejor alternativa? Bit? Tinyint? Char?
>
>
>