VARCHAR像90年代一样吗？

Question

1. VARCHAR不存储Unicode字符.
2. NVARCHAR存储Unicode字符.
3. 今天的应用程序应始终与Unicode兼容.
4. NVARCHAR需要两倍的空间来存储它.
5. 第4点无关紧要,因为存储空间非常便宜.

Ergo:今天设计SQL Server数据库时,应始终使用NVARCHAR.

这听起来有道理吗？有没有人不同意任何前提？今天有没有理由在NVARCHAR上选择VARCHAR？

Answer 1

您将数据类型与将存储在列中的数据相匹配.通过类似的参数,您可以说为什么不将所有数据存储在NVARCHAR列中,因为数字和日期可以表示为数字字符串.

如果将存储在列中的数据的最佳匹配是VARCHAR,则使用它.

Answer 2

第4点无关紧要,因为存储空间非常便宜.

它不仅仅是存储,而是带宽 - CPU,内存,备份,恢复,传输.养护.

Answer 3

我会说仍然有正当理由不使用nvarchar.

• 存储空间非常宝贵,例如在共享主机上,或者数据库 非常庞大.
• 表现至关重要.
• Brownfield开发(即数据库具有使用varchar的现有表).
• 您正在与另一个只能理解单字节字符和/或varchar的旧系统集成.

但是,新开发应该使用nvarchar esp.因为64位系统正在成为常态.此外,公司(即使是小公司)现在更普遍是全球性的.

Answer 4

对于许多不同类型的列,您应该为NVARCHAR选择VARCHAR,并且选择将基于每列.

不需要NVARCHAR额外开销的典型列将是:

ID类型列:车牌,SSN,患者图表标识符等.

代码栏:国际货币代码(USD,UKP等),ISO国家代码(美国,英国等),语言代码(en-us等),会计分部代码等

邮政编码和邮政编码列.

Answer 5

我相信nvarchars的比较比varchars更昂贵,因此它非常有效,甚至在你真正不需要unicode功能的地方,即一些内部ID.

存储成本仍然很重要.如果你有数十亿行,那么这些"小"差异会变得非常快.

Answer 6

正如其他人所指出的那样,不仅仅是存储成本.

列的长度将影响每页的行数.每页的行数减少意味着您的缓存中可以容纳更少的行,这会降低性能.我假设在MSSQL中,索引的NVARCHAR列将占用索引中更多的空间.这意味着每个块的索引条目越少,因此索引中的块越多,因此在扫描(或搜索)索引时会有更多的搜索,这也会降低索引访问的速度.

所以它在每一个方面都会失去你的表现.如果你真的不关心(或者可以衡量表现并且对它感到满意),那就没关系了.但是,如果您真正需要存储unicode字符,当然要使用NVARCHAR.

我可能认为在整个数据库中使用NVARCHAR所获得的可维护性超过任何性能成本.

Answer 7

这些问题总是有相同的答案:这取决于.你应该盲目追随没有神奇的规则.即使在现代编程语言中使用GOTO也是合理的:在支持循环和函数的语言中使用'goto'是否有利？如果是这样,为什么？

所以答案是:用你的头脑思考特定的情况.在这个特定的实例中,请记住,如果结果证明您的需求发生了变化,您始终可以在数据库中将varchar转换为nvarchar.