数据库中所有包含文本的列过去都是 nvarchar，但出于性能原因，我们将它们转换为 varchar。我现在剩下的所有 SqlParameters 仍在使用 SqlDbType.NVarChar 并且我想将它们更改为 SqlDbType.VarChar 但如果我看不到更改它们的任何好处，我不想浪费时间这样做。是否值得更改它们，还是我在浪费时间？
我对 varchar 和 nvarchar 之间哪个更好不感兴趣。我想知道如果数据库中的所有字段都是 varchars，将 SqlParameter.SqlDbType 从 SqlDbType.NVarChar 更改为 SqlDbType.VarChar 是否会有所不同。
【问题讨论】：
标签： .net sql sql-server
更改代码的好处是它应该与数据库匹配。如果您的列现在是 varchar，则应该将它们作为 varchar 访问。
不这样做可能意味着您最终会在数据库中错误地编码文本或将单字节字符读取为双字节字符。你冒着破坏所有文本的风险。
【讨论】：
SqlDbType.VarChar，您会遇到问题。你应该保持你的代码一致，如果不是为你，那么为下一个人。
我同意 Oded 关于为下一个人保持代码一致的说法。虽然从技术上讲，可能没有任何好处，但应该始终牢记下一个人。我很高兴能协调 75 个数据库，这些数据库虽然具有完全相同的版本号，但在结构上都不同。有些强制执行外键约束，有些则没有。有些定义了主键，有些没有。但是，相同的代码库正在与所有这些人交谈。去搞清楚。他们之所以这样，是因为几年前有人采取了一些节省时间的捷径。然后是别人。然后是别人。等等等等。现在这是一团糟，试图解决它是一场噩梦。
此处应取代可维护性和可读性。毕竟总有一天会有人过来对自己说：“我在这里很困惑。这应该是怎么回事？嗯......代码都说NVarChar，数据库是VarChar......我知道需要NVarChars为了全球化，我们可能有一天想要全球化这个东西......”接下来你知道，你已经失去了性能提升，因为这个人将所有数据库字段都改回了 NVarChars。
【讨论】：
如果您使用 NVARCHAR 参数，我希望使用当前数据库的默认排序规则将它们转换为 varchar：有关详细信息，请参阅 this article。
因此，除非您在数据库中使用多个排序规则，否则我预计不会出现问题。如果您使用 NVARCHAR，您可能会通过线路发送更多数据，但数据量必须非常大，才能对性能产生明显影响。
顺便说一句，我发现 Sybase 12 存在问题 - 如果您在 WHERE 子句中使用 NVARCHAR 参数作为条件来与索引的 VARCHAR 列进行比较，Sybase 12 将执行表扫描，而不是自动将参数转换为VARCHAR 并使用索引。在我们了解发生了什么之前，这在过去给我们造成了一些奇怪的性能问题。这里的解决方案是将参数显式发送为 varchar。
【讨论】：
以上所有内容都是高端用户的好答案。这是一个小恶魔的拥护者。 我不是说我是对的，我是说这里值得深思。如果您的数据库是通用的/足够小和/或您希望能够轻松切换数据库，nvarchar 可能是更好的选择。我们经常谈论层的分离。我们将数据库与代码耦合得越紧密，即插即用就越难。虽然使用正确的数据类型可以提高性能，但如果由于新的国际目的而为 nvarchar(100) 重新创建/更新了最初存储 varchar(50) 的字段怎么办？是的，我们可以重写我们的代码，是的，我们可能决定创建一个新项目......但是如果我们构建了足够通用的代码以访问新的数据库需求呢？那是即插即用和良好的代码IMO。因此，在我看来，其中一些最喜欢的旧数据类型已经过时了。但是，对于大多数较旧的数据库，我仍然同意其他人的观点，答案一如既往：视情况而定。
【讨论】：