NCHAR(1)与BIT [英] NCHAR(1) vs BIT
问题描述
我正在数据库重构(SQL Server 2008)方案下工作，并收集参数以将NCHAR(1)列(保留Y|N值)更改为BIT.每个人都知道这是必要的，并且不知道为什么会发生，但是此更改会影响生产数据库，因此需要很重要的参数.该表保留了地址目录(最多1m条记录).
I'm working under refactoring of database (SQL Server 2008) scheme and gather arguments to change NCHAR(1) columns (which keep Y|N values) to BIT. Everybody understand this is necessary and don't know why does it take place but this change affects production database so weighty arguments are required. Table keeps address catalog (up to 1m of records).
我发现的第一个参数-每个 nchar字段占用2个字节，每个8个位字段-1个字节(下一个8-附加1字节).
First argument I found - each nchar fields take 2 bytes, each 8 bit fields - 1 byte (next 8 - additional 1 byte).
下一步是什么?也许某些索引性能问题?
What's next? Maybe some indexes performance issues?
推荐答案
位字段通过自动强制执行当前隐式业务规则(即，此列只能包含"Y"或"N")来帮助您的逻辑.如果您以编程方式强制执行该规则，则可以通过消除该开销来节省费用.由于基数低，因此仅对位列进行索引的价值很小，但它可以用作复合索引的一部分.
A bit field helps your logic by automatically enforcing what is currently an implicit business rule (i.e., this column can only contain 'Y' or 'N'). If you're enforcing that rule programmatically, you can save by eliminating that overhead. Indexing a bit column on its own has little value due to the low cardinality, but it could be useful as part of a composite index.
另请参阅:
- Bit vs. Char(1) in SQL Server
- Should I index a bit field in SQL Server?
这篇关于NCHAR(1)与BIT的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
