6

我现在正在设计一个数据库方案，我认为为了安全起见，我应该将 nvarchar 用于我的文本列的数据类型（用于 unicode 支持）。虽然我不期望非英语文本，但我认为最好从一开始就支持它以防万一。

我有什么理由坚持使用普通的varchar？表现？

4

6 回答 6

11

在当今的 i18n 世界中，nvarchar 很有意义。varchar 对于指定为非 unicode的数据可能有意义（也许您有一些要求为 ASCII 的系统字段）。

默认情况下，我会使用 nvarchar 来表示名称、描述、地址等。

varchar更小，因此varcharover可能会节省一些 IO nvarchar（但请注意，代码页也成为一个更大的问题）。

于 2009-02-16T07:54:07.733 回答
4

另外，请参阅此问题：VARCHAR 与 NVARCHAR 性能。

就个人而言，我说坚持使用 varchar（正如我在这个帖子中回答的那样）。有一个重要的性能开销。

于 2009-02-16T07:59:58.670 回答
2

我们几乎对所有事情都使用 VARCHAR，而 NVARCHAR 只是非常非常偶尔。

产品代码不需要 NVarchar - 我们不允许在其中包含 AZ、0-9 和“_”以外的任何内容......

它是存储空间的两倍，但每个索引页（和每个数据页）只有一半的条目，一半的内存缓存被“浪费”，更多的 CPU 周期来比较数据，等等。

IME 常用的外国口音只能在 Varchar（即 LATIN-1）中找到。我们没有计划制作中文或其他替代字符集，并且当我们能够通过从第一天开始使用 NVarchar 来处理该字符集时，我们最不担心 - 从右到左或垂直对齐文本？:(

如果您允许使用 NVarchar 作为名称，您将如何从键盘输入扩展字符？如果您导入数据（因此它已经是 NVarchar），您将如何使用标准 QWERTY 键盘搜索该客户。国际化应用程序涉及很多很多，所以我的观点是“通过使用 NVarchar 来允许它”是没有意义的。

但是我又去很多地方有 NVarchar ......而且大多数列也是 50 个字符宽......他们必须知道一些我不知道的关于邮政编码的人口增长和扩张计划！

于 2009-02-16T09:33:36.700 回答
1

是的，性能，尺寸。nvarchar 占用更多字节，我认为它是双倍的（如果我错了，请纠正我），这是因为 unicode 支持。因此，如果您不需要 unicode 支持，请使用常规 varchar。

于 2009-02-16T07:52:47.877 回答
1

如前所述，权衡是面向未来与性能。以我的经验，SQL Server 在 CPU 和内存限制较低的情况下表现相当不错，但是给它一个缓慢的磁盘 I/O 并且它真的可以突突。

如果您没有双字节字符集（即汉字）的计划，请坚持使用 VARCHAR(MAX)。

于 2009-02-16T23:18:44.813 回答
0

通常来说，一般来说; 从约束最少的最昂贵的数据类型开始。将其投入生产。如果性能开始成为问题，请找出这些 nvarchar 列中实际存储的内容。里面有没有不适合 varchar 的字符？如果没有，请切换到 varchar。在你知道痛苦在哪里之前，不要尝试预先优化。我的猜测是 nvarchar/varchar 之间的选择不会在可预见的未来减慢您的应用程序的速度。在应用程序的其他部分中，性能调整将为您带来更多收益。

于 2013-02-22T07:44:18.560 回答