如果數據庫中的所有列都是 varchars，使用 SqlDbType.VarChar 而不是 SqlDbType.NVarChar 有什么好處

Question

數據庫中包含文本的所有列過去都是 nvarchar，但出於性能原因，我們將它們轉換為 varchar。 我現在剩下的所有 SqlParameters 仍然使用 SqlDbType.NVarChar，我想將它們更改為 SqlDbType.VarChar，但如果我不會看到更改它們的任何好處，我不想浪費時間。 值得改變它們還是我在浪費時間？

我對 varchar 和 nvarchar 之間哪個更好不感興趣。 我想知道如果數據庫中的所有字段都是 varchars，將 SqlParameter.SqlDbType 從 SqlDbType.NVarChar 更改為 SqlDbType.VarChar 是否會有任何區別。

Answer 1

更改代碼的好處是它應該與數據庫匹配。 如果您的列現在是 varchar，則應將它們作為 varchar 訪問。

不這樣做可能意味着您最終會在數據庫中錯誤地編碼文本或將單字節字符讀取為雙字節字符。 您冒着損壞所有文本的風險。

Answer 2

我同意 Oded 關於為下一個人保持代碼一致的聲明。 雖然從技術上講，可能沒有任何好處，但應該始終牢記下一個人。 我有一種令人懷疑的樂趣，可以協調 75 個數據庫，雖然它們具有完全相同的版本號，但在結構上卻各不相同。 有些強制執行外鍵約束，有些則沒有。 有些定義了主鍵，有些沒有。 但是，相同的代碼庫正在與所有這些人交談。 去搞清楚。 他們這樣做是因為幾年前有人采取了一些節省時間的捷徑。 然后是別人。 然后是別人。 等等等等。現在它是一團糟，試圖解決它是一場噩夢。

可維護性和可讀性應該在這里取代。 畢竟總有一天有人會過來對自己說，“我在這里很困惑。這應該是怎么回事？嗯……代碼都說 NVarChar，數據庫是 VarChar……我知道需要 NVarChars為了全球化，我們可能有一天想要全球化這個東西......”接下來你知道，你已經失去了性能提升，因為這個家伙將所有數據庫字段都改回了 NVarChars。

Answer 3

如果您使用 NVARCHAR 參數，我希望它們使用當前數據庫的默認排序規則轉換為 varchar：有關更多信息，請參閱此文章。

因此，除非您在數據庫中使用多個排序規則，否則我不會期望出現問題。 如果您使用 NVARCHAR，您可能會通過網絡發送更多數據，但數據量需要非常大才能對性能產生明顯影響。

順便說一句，我已經看到 Sybase 12 的問題 - 如果您在 WHERE 子句中使用 NVARCHAR 參數作為與索引 VARCHAR 列進行比較的條件，則 Sybase 12 將執行表掃描而不是自動將參數轉換為 VARCHAR 並使用指數。 過去這給我們帶來了一些奇怪的性能問題，直到我們了解發生了什么。 這里的解決方案是顯式地將參數作為 varchar 發送。

Answer 4

以上都是高端用戶的好答案。 這是一個小惡魔的擁護者。 我不是說我是對的，我是說這里值得深思。 如果您的數據庫足夠通用/足夠小和/或您希望能夠輕松切換數據庫，nvarchar 可能是更好的選擇。 我們經常談論層的分離。 我們將數據庫與代碼結合得越緊密，即插即用就越難。 雖然使用正確的數據類型會提高性能，但如果由於新的國際目的而為 nvarchar(100) 重新創建/更新最初存儲 varchar(50) 的字段怎么辦？ 是的，我們可以重寫我們的代碼，是的，我們可能決定創建一個新項目……但是，如果我們構建的代碼足夠通用以訪問新的數據庫需求呢？ 即插即用和良好的代碼 IMO。 因此，在我看來，這些舊的最喜歡的數據類型中的一些已經過時了。 但是，對於大多數較舊的數據庫，我仍然同意其他人的看法，答案一如既往：視情況而定。