2011-08-30 11 views
12

I tiene una columna calculada que necesito ser un campo de bits, aquí un ejemplo de fórmula:¿Cómo podría forzar el tipo de datos de una columna calculada a un campo de bit que no permite valores nulos?

case when ([some_field] < [Some_Other_field]) 
then 0 
else 1 
end 

El tipo de datos de conjunto de columnas calculada utilizando esta fórmula es int.

¿Cuál es la mejor manera de forzar el tipo de datos correcto?

Con una declaración CONVERT sobre todo el caso, el tipo de datos es bit pero Allow Nulls

CONVERT([bit], 
     case when (([some_field] < [Some_Other_field]) 
     then 0 
     else 1 
     end, 
     0) 

Lo mismo con una declaración CONVERT en las expresiones de resultado, el tipo de datos es bit pero Allow Nulls

case when (([some_field] < [Some_Other_field]) 
then CONVERT([bit], (0), 0) 
else CONVERT([bit], (1), 0) 
end 

¿O hay una manera más inteligente de hacer esto?

Respuesta

21

Ajustar la definición de columna calculada en ISNULL, con lo que desee como segundo argumento (siempre que sea un poco, o convertible a tal).

Este es uno de los pocos lugares en los que tiene que usar ISNULL en lugar de (el diseño generalmente mejor) COALESCE. SQL Server tiene una lógica de caso especial para darse cuenta de que un ISNULL con un segundo argumento no nulo representa un resultado que no admite nulos.

ej .:

ISNULL(CONVERT(bit,case when ([some_field] < [Some_Other_field]) 
then 0 
else 1 
end),0) 

Esto también se puede utilizar en, por ejemplo, ver definiciones

+0

¿Usted o alguien tiene una idea de si hay diferencias de rendimiento entre el ejemplo y la siguiente sintaxis alternativa: 'caso cuando ([some_field] <[Some_Other_field]) continuación ISNULL (CONVERTIR (bit, 0) , 0) else ISNULL (CONVERTIR (bit, 1), 1) end'? – tomosius

+0

@tomosius - No esperaría una * diferencia medible * en el gran esquema de cosas (por ejemplo, los costos de E/S relacionados con el acceso a datos y los gastos generales de red). También sospecho que su variante puede reintroducir el mismo problema que la pregunta trató de evitar: que las expresiones 'CASE' se analizan con frecuencia como potencialmente NULLables aunque por inspección sabemos que no. –

Cuestiones relacionadas