如果数据库中的所有列都是varchars，那么使用SqlDbType.VarChar而不是SqlDbType.NVarChar是否有任何好处

Question

数据库中包含文本的所有列曾经是nvarchar，但出于性能原因我们将它们转换为varchar。我现在所有的SqlParameters仍然使用SqlDbType.NVarChar，我想将它们更改为SqlDbType.VarChar但我不想浪费时间去做，如果我不会看到更改它们的任何好处。值得改变它们还是我在浪费时间？

我对varchar和nvarchar之间的哪个更好感兴趣。我想知道如果将SqlParameter.SqlDbType从SqlDbType.NVarChar更改为SqlDbType.VarChar，如果数据库中的所有字段都是varchars，则会有任何不同。

Answer 1

更改代码的好处是它应该与数据库匹配。如果您的列现在是varchar，则应该将它们作为varchar访问。

不这样做可能意味着您最终在数据库中编码错误的文本或将单字节字符读取为双字节字符。你冒着破坏所有文本的风险。

Answer 2

我同意Oded关于为下一个人保持代码一致的声明。虽然从技术上讲，可能没有任何好处，但应该始终牢记下一个人。我很高兴能够协调75个数据库，虽然它们具有完全相同的版本号，但它们在结构上都是不同的。有些人强制执行外键约束，有些则没有。有些人定义了主键，有些则没有定义。但是，相同的代码库正在与所有这些代码进行讨论。去搞清楚。他们之所以这样，是因为几年前有人节省了一些时间。别人。别人。现在这是一个很大的混乱，这是一个噩梦，试图解决它。

可维护性和可读性应该在这里取代。毕竟有一天有人会过来对自己说：“我在这里很困惑。这是怎么回事？嗯......代码都说NVarChar，数据库是VarChar ......我知道需要NVarChars对于全球化而言，我们有朝一日可能希望将这个事情全球化......“接下来你知道，你已经失去了性能提升，因为这个人将所有的数据库字段都改回了NVarChars。

Answer 3

如果您使用的是NVARCHAR参数，我希望使用当前数据库的默认排序规则将它们转换为varchar：有关详细信息，请参阅this article。

因此，除非您在数据库中使用多个排序规则，否则我不会发现问题。如果你使用NVARCHAR，你可能会通过网络发送更多数据，但是这个数量需要非常大才能对性能产生明显的影响。

顺便说一下，我看到了Sybase 12的问题 - 如果您使用NVARCHAR参数作为WHERE子句中的条件与索引的VARCHAR列进行比较，Sybase 12将执行表扫描而不是自动将参数转换为VARCHAR并使用索引。在我们理解正在发生的事情之前，这导致了我们过去一些奇怪的性能问题。这里的解决方案是显式地将参数发送为varchar。

Answer 4

以上所有内容都是高端用户的不错答案。这是一个小魔鬼的拥护者。 我并不是说我是对的，我是在说这是值得深思的。如果您的数据库足够通用/较小，并且/或者您希望能够轻松切换数据库，那么nvarchar可能是更好的选择。我们经常谈论层分离。我们将数据库与代码的耦合越紧密，即插即用的难度就越大。尽管使用正确的数据类型可以提高性能，但是如果由于新的国际目的为nvarchar（100）重新创建/更新了最初存储varchar（50）的字段，该怎么办？是的，我们可以重写代码，是的，我们可以决定创建一个新项目...但是，如果我们构建的代码足够通用，可以访问新的数据库要求呢？即插即用和良好的代码IMO。因此，在我看来，其中一些旧的最喜欢的数据类型是过时的。但是，对于大多数较旧的数据库，我仍然同意这些人的看法，答案还是一如既往：这取决于。