Estoy trabajando bajo el esquema de refactorización de la base de datos (SQL Server 2008) y reúno los argumentos para cambiar las columnas NCHAR(1)
(que guardan los valores Y|N
) a BIT
. Todos entienden que esto es necesario y no sé por qué ocurre, pero este cambio afecta a la base de datos de producción por lo que se requieren argumentos de peso. La tabla mantiene el catálogo de direcciones (hasta 1 m de registros).NCHAR (1) vs BIT
Primer argumento que encontré - cada nchar fields toma 2 bytes, cada 8 bit fields - 1 byte (8 siguientes - 1 byte adicional).
¿Qué sigue? Tal vez algunos problemas de rendimiento de índices?
¡Se pregunta por qué el diseñador original decidió que unicode era necesario para almacenar solo 'N' e 'Y'!Sospecho que las comparaciones probablemente serán más rápidas en los campos de bit que en los campos 'nchar', pero no lo sé con certeza. –
Obviamente, la ventaja de 'NCHAR (1)' es que puede expandirlo [cuando sea necesario] (http://thedailywtf.com/Articles/What_Is_Truth_0x3f_.aspx) - para contener * otros * valores booleanos. ;-) –
@Dean Harding: LOL. Una vez tuve un [PHB] (http://en.wikipedia.org/wiki/Pointy-haired_Boss) insistir en que podríamos poner un 2 en un campo de bit ya que solo tenía un dígito. –