我將本地化的字符串存儲在使用MS Sql（2008或其他）的單個數據表中。大多數字符串都很短，可以用varchar（200）表示，而大約10％的字符串需要varchar（5000）之類的東西。我的問題是，是否有更短的檢索字符串時，性能上的優勢，如果我打破了這種成兩個表是這樣的：SQL nvarchar性能
CREATE TABLE ShortTextTable(ID bigint IDENTITY(1,1) NOT NULL, TextValue nvarchar(200))
CREATE TABLE LongTextTable(ID bigint IDENTITY(1,1) NOT NULL, TextValue nvarchar(4000))
對戰：
CREATE TABLE TextTable(ID bigint IDENTITY(1,1) NOT NULL, TextValue nvarchar(4000))
這些數據將很少更新，我只是很真正關心讀取。
這取決於。可能是過早的優化。
對於較小的列，很明顯，每頁將顯示更多的行，但是您的使用模式可能意味着您提議的水平分區效率不高，因爲它從兩個新表中獲取內容。我想我們需要看到讀取的使用模式以及表格的連接方式。
而且，它是分區的空間在邏輯上是一個空間，將不再管理爲一體的空間（即在兩個地方添加索引等）
你真的要還得看瓶頸和配置文件提出的變化之前，我會這樣分區。
我不確定，但它可能是字面分區（使用SQL Server的分區表功能）基於列的長度的表。再次，這是否會有所幫助需要進行分析。
不，沒有真正的收益。爲了看到由於字符串大小交錯造成的瓶頸，特別是基礎不使用int PK，這將是一個真正的極端。
另一方面，使用這樣的存儲模式的混亂是非常清楚和現在：你必須根據字符串的長度來決定你還沒有檢索在哪張表上看！您可能最終會通過試驗和錯誤（嘗試一個表，然後另一個表），這比任何表nvarchar存儲結構問題浪費得多。
在SQL 2005中，我相信2008你不會創建一個NVarChar（5000），因爲你超過了這種數據類型的頁面大小，NVarChar（Max）會在那個時候工作。當爲nVarChar指定一個數字N時，您的限制可達4000.
我相信在這一點上，讀取內聯存儲值與頁面之間會有性能差異，讀取頁面以獲取16字節指針指向LOB頁面並從那裏讀取數據。
否或負增益，
寄存明智： 一種可變長度的字符串被存儲作爲字符+ 2個字節用於長度的數目。所以：數據的長度是相同的，但是你有第二個表的索引和鍵值開銷。
加工明智：
現在，更重要的是，我看到你提到的本地化，但你需要nvarchar？另一個SO問題：varchar vs nvarchar performance
關於過早優化的好處。出於這個原因，我會堅持單桌設計。 – Paul 2009-07-13 19:23:52
另一個問題是，使用2個表格，您將不再能夠輕鬆創建單個外鍵約束。 – 2009-07-13 21:01:42