NCHAR(1)vs位

位字段通过自动执行当前隐式业务规则(即,此列只能包含“Y”或“N”)来帮助您的逻辑。如果以编程方式强制执行该规则,则可以通过消除该开销来节省开销。由于基数较低,单独索引位列的价值不大,但它可以作为复合索引的一部分。

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

除非你有充分的理由做出这样的改变,否则我不会为这种改变提供任何论据。i、 e.你必须平衡改变的成本与你个人所做/喜欢的事情,以及实际实施的成本和好处。

您是否检查过使用nchar(1)是否会损害性能,或者是否落入过早优化的陷阱?你说的只是一百万张唱片。

找到NCHAR(1)而不是bit的一个常见原因是Oracle不支持位类型。如果你有一个甲骨文或甲骨文训练有素的开发人员,或是一个在甲骨文上运行的数据库,你会看到很多。在Sql Server中,确实不需要这样做。

真正地 want是一个datetime,它指示的不是标志值的多少,而是它何时变为真。这种情况并不总是这样,但当我回想起我写的旧代码时,我猜5次中有4次我使用了位字段,我应该使用datetime。

创建位字段,添加一个模拟nchar(1)的计算列。

不使用nchar的内容:

• Y y 对一些 unicode Y
• 不是天生的“真”或“假”(例如不会直接映射到.net布尔值)
• 是的 和 N

• 较小
• 直接映射到客户的意思
• 独立于地区

也就是说,我们使用smalldatetime“WhenInactive”字段代替“IsActive”字段。空=活动。

如果您使用的是LINQ2SQL或实体框架 BIT 列将转换为 bool ,但是 NCHAR(1) 将转化为 string

字段是否广泛用于查询 Where fld = 'Y' ?

如果是这样的话,我会考虑做一个测试,看看把它改成bit是否会影响性能。

使用位:

• 逻辑表示/意图的表达-因为布尔状态并不总是像 Yes or No ,这意味着您要么需要在建模位上不一致,要么不直观,例如。 True/False (T/F) , On/Off (?O/F) Open/Closed(O/C)

• 引用完整性-不可为空的位只能限制为 0 or 1 . 除非添加约束,否则 *char(1) 可以是 Y N , X 或 ☺ .

• Bits can be packed ,所以可以有更小的存储空间。

• 关于:性能:位(或少数状态字符)列的索引通常是一种浪费,除非数据中有0或1的高选择性。在这种情况下 filtered index 关于选择值是个好主意。

deleted answer here