NCHAR(1)与BIT

Question

我在数据库重构(SQL Server2008)方案下工作，收集参数以将NCHAR(1)列(保留Y|N值)更改为BIT。每个人都知道这是必要的，也不知道为什么会发生这种变化，但这种变化会影响生产数据库，因此需要重要的参数。表保存地址目录(最多1m条记录)。

我发现的第一个参数--每个nchar fields占用2个字节，每个8个bit fields -1个字节(下一个8-额外的1个字节)。

下一步是什么？也许是一些索引性能问题？

Answer 1

位字段通过自动执行当前隐含的业务规则(即，此列只能包含'Y‘或'N')来帮助您的逻辑。如果您以编程方式执行该规则，则可以通过消除该开销来节省成本。由于基数较低，对位列本身进行索引的价值很小，但作为复合索引的一部分，它可能很有用。

另请参阅：

• Bit vs. Char(1) in SQL Server
• Should I index a bit field in SQL Server?

Answer 2

除非你有很好的理由做出这样的改变，否则我不会为这种改变提供任何论据。也就是说，你必须平衡改变的成本与你个人想要做/喜欢的事情，以及实际实现它的成本和好处。

您是否检查过nchar(1)的使用是否会损害性能，或者是否落入了过早优化的陷阱？你在这里只谈到了一百万条记录。

对于您认为产生的较小的存储/ IO成本，请考虑更改、重新测试和升级系统的总工时*小时费率与仅购买更快磁盘的成本。我怀疑这个磁盘会便宜得多--同时也会让系统的各个方面受益。

Answer 3

查找NCHAR(1)而不是bit的一个常见原因是Oracle不支持bit类型。如果您有一位Oracle或受过Oracle培训的开发人员，或者曾经在Oracle上运行的数据库，您将会经常看到这种情况。在Sql Server中，真的不需要这样做。

然而，我发现大多数地方我有一个位字段(或Oracle中的NCHAR(1) )，我真正想要的是一个日期时间，它指示的不是标志的值，而是它成为true的确切时间。情况并不总是这样，但当我回想起我写的旧代码时，我会猜测我使用位字段的5次中有4次应该使用datetime。