如果数据库中所有列都是varchars，使用SqlDbType.VarChar而不是SqlDbType.NVarChar有什么好处吗？

Question

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

我不关心varchar和nvarchar哪一个更好。我想知道如果数据库中所有字段都是varchar，那么将SqlParameter.SqlDbType从SqlDbType.NVarChar更改为SqlDbType.VarChar是否会有任何影响。

- SQL Master

Answer 1

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

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

- Oded

---

使用SqlDbType.NVarChar并没有破坏字符，据我所见。我已经这样使用了几个月，没有任何问题。 - SQL Master

可能是因为你保持了一致性。如果另一个应用程序使用了 SqlDbType.VarChar，那么你就会遇到问题。你应该保持代码的一致性，即使不是为了你自己，也要为了下一个人。 - Oded

Answer 2

我赞同Oded的观点，即要为下一个人保持代码的一致性。虽然从技术上讲可能没有任何好处，但我们应该始终牢记下一个人的需求。我有一个不幸的经历，需要调和75个数据库，尽管它们具有完全相同的版本号，但结构却各不相同。有些强制执行外键约束，有些则没有。有些定义了主键，而有些则没有。但同样的代码库正在与它们进行通信。这是怎么回事呢？它们变成这样是因为几年前有人采取了一些节省时间的捷径。然后是其他人。再然后是其他人。等等等等。现在它变成了一团糟，试图整理它是一场噩梦。

在这里，可维护性和可读性应优先考虑。毕竟，总有一天会有人来到这里，并对自己说：“我在这里感到困惑。这应该是怎样的？嗯...代码都写着NVarChar，而数据库是VarChar...我知道NVarChar对于全球化很重要，我们可能希望将其全球化...”接下来，你就失去了性能提升，因为这个人将所有数据库字段都改回了NVarChar。

- Steve Elmer

---

我认为你比Oded更好地解释了一致性的原因，并且你提到了如果他们看到NVarChar可能会出现的潜在问题，这是一个很好的观点。谢谢。 - SQL Master

Answer 3

如果你正在使用NVARCHAR参数，我会期望它们被转换为使用当前数据库的默认排序顺序的varchar：请参阅this article以获取更多信息。

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

另外，我曾经在Sybase 12中遇到过问题 - 如果你将NVARCHAR参数作为WHERE子句中与索引的VARCHAR列进行比较的条件，Sybase 12会执行表扫描而不是自动将参数转换为VARCHAR并使用索引。这在过去给我们带来了一些奇怪的性能问题，直到我们理解了发生了什么。解决方法是明确地将参数发送为varchar。

- Joe

Answer 4

以上都是高端用户的好答案。这里有一个小小的反对者观点。我不是说我是对的，我只是提供一些思路。如果你的数据库足够通用/小，并且/或者你想轻松切换数据库，nvarchar可能是更好的选择。我们经常谈论分层。我们将数据库与代码耦合得越紧密，就越难以插拔。虽然使用正确的数据类型可以提高性能，但如果原来存储varchar（50）的字段由于新的国际目的而重新创建/更新为nvarchar（100），怎么办？是的，我们可以重写我们的代码，是的，我们可能会决定创建一个新项目...但是，如果我们构建的代码足够通用，以便访问新的数据库要求呢？那就是插拔式和良好的代码，我认为。因此，我认为一些旧的喜爱数据类型已经过时了。然而，对于大多数旧数据库，我仍然同意这些其他人的答案：这取决于情况。

- Patrick Knott