VARCHAR像90年代一样吗？

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

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

1> dkretz..：

---

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

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

2> Sam..：

---

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

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

3> Booji Boy..：

---

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

存储空间非常宝贵,例如在共享主机上,或者数据库 非常庞大.

表现至关重要.

Brownfield开发(即数据库具有使用varchar的现有表).

您正在与另一个只能理解单字节字符和/或varchar的旧系统集成.

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

---

双宽字符占用了两倍的内存,但这在64位系统上要小得多,因为它们可以处理比32位系统多得多的RAM.32位Windows上的32位SQL Server(在08年仍然很常见)只能使用2 GB RAM(没有跳过篮球)

4> Cade Roux..：

---

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

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

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

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

邮政编码和邮政编码列.

5> PiRX..：

---

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

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

6> MarkR..：

---

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

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

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

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

7> Brannon..：

---

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

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