SqlServer和nvarchar（最大）

我們目前正在考慮將字符串列設置爲nvarchar(max)，而不是指定特定的長度以防止數據庫中沒有足夠空間存儲字符串的問題。林只是想知道這是一件好事，或者它可以導致任何問題，因爲它可以做，那麼爲什麼指定一個長度，如nvarchar(10)，而不是nvarchar(max)。我們也使用varbinary(max)很多，因爲我們不知道我們需要多少二進制數據，所以我不知道這是一個效果多少，或者讓我們的插入速度沒有我認爲應該的那麼快。這是一個示例表：SqlServer和nvarchar（最大）

CREATE TABLE [dbo].[SAMPLETABLE] ( 
[ID] [uniqueidentifier] NOT NULL, 
[FIELD1] [int] NOT NULL, 
[FIELD2] [nvarchar] (2000) NULL, 
[FIELD3] [nvarchar] (max) NULL, 
[FIELD4] [uniqueidentifier] NULL, 
[FIELD5] [int] NULL, 
[FIELD6] [nvarchar] (2000) NULL, 
[FIELD7] [varbinary] (max) NULL, 
[FIELD8] [varbinary] (max) NULL, 
[FIELD9] [varbinary] (max) NULL, 
[FIELD10] [uniqueidentifier] NULL, 
[FIELD11] [nvarchar] (2000) NULL, 
[FIELD12] [varbinary] (max) NULL, 
[FIELD13] [varbinary] (max) NULL, 
[FIELD14] [bit] NULL, 
[FIELD15] [uniqueidentifier] NULL, 
[FIELD16] [varbinary] (max) NULL, 
[FIELD17] [bit] NULL, 
[FIELD18] [tinyint] NULL, 
[FIELD19] [datetime] NULL, 
[FIELD20] [nvarchar] (2000) NULL, 
PRIMARY KEY CLUSTERED 
( 
    [ID] ASC 
) 
) ON [PRIMARY] 

GO

給定一個表的設計一樣，並改變nvarchar(2000)到nvarchar(max)將讓事情更糟（或更好）？ sqlserver是否對這樣的設計皺眉頭？

來源

2011-02-02 user455095

你存儲什麼樣的數據？唯一的*問題*將是索引，搜索和約束。儘管如此，這並不是一個好主意。 – Matthew 2011-02-02 17:57:16

**請不要這樣做！**如果我在一個擁有這樣的桌子的地方被僱用，我會跑出大門！然後，在所有nvarchar（max）列yuck頂部添加聚簇uniqueidentifier PK。你正在殺死你索引數據的能力。不久的將來，你會回過頭來問一個關於你的查詢運行速度如此緩慢的問題，並且不會有太多的事情可以加快速度。當天，所有主流/流行語言都是強類型的，但現在還沒有那麼多。如果你嘗試在數據庫中使用「那個」柺杖，你會遇到問題。 – 2011-02-02 19:40:21

@KM如果可以的話，我會百萬次提出你的評論，這是可怕的數據庫設計。 – HLGEM 2011-02-02 20:24:09

如果你對J. Random Developer感到滿意，在6個月後，將莎士比亞的作品插入到每一欄中，那麼很好。

對我來說，數據建模的一個重要部分是認真考慮我想在每列中允許的數據以及我希望禁止的數據。然後我應用適當的約束來實現這些限制（如同最好的SQL Server允許的那樣）。有一個明智的長度檢查可用「免費」總是看起來像一個獎金。

你也沒有做太多的「未來驗證」 - 在日後改變（n）的VARCHAR列到一個較大的值的長度，我相信，一個純粹的元數據操作。所以我會說適當的大小列的數據，你今天要處理的數據（和好的，未來一年左右）。如果您需要稍後擴展它，則需要幾秒鐘的時間。

來源

2011-02-02 15:19:03

答案與「爲什麼我需要指定int時，我可以將所有數字存儲爲字符串？」的答案相同。 - 因爲它幫助：

速度的效率。
存儲效率。
作者/建築師的意圖。
減少了數據錯誤，因爲只有某種數據才適合。

但是它不會立即引起任何明顯的「問題」，因爲nvarchar（10）是nvarchar（max）的一個子集。

來源

2011-02-02 15:20:17 iain

我們希望您不要使用列搜索或具有唯一值...

索引不能超過寬900字節，因此，你可能永遠無法創建索引。這是一個缺點：因爲它給

非常糟糕的搜索性能
沒有唯一約束

它可以圍繞與計算列來工作，但爲什麼不儲存你需要？

來源

2011-02-02 17:50:41 gbn

從行內類型切換到BLOB類型始終是一個重大決定。你必須內化的BLOB類型（VARCHAR(MAX)，NVARCHAR(MAX)和VARBINARY(MAX)）是完全不同的，從行內類型內部類型：

他們去到不同的分配單元，看到Table and Index Organization
它們不能是索引
的到不同的存儲選項視在sp_tableoption
他們使用完全不同的處理的代碼路徑，看到Performance comparison of varchar(max) vs. varchar(N)
在線運在帶有BLOB的表上不允許使用表（請參閱ALTER INDEX ... REBUILD ... WITH (ONLINE= ON)處的例外情況。估計是因爲你的表已經有BLOB的，這不會是一個問題

所以切換所有列BLOB類型有很多副作用，可能會帶給你有沒有考慮過：不可能建立索引的BLOB列，缺乏的在線操作，由於BLOB固有的較慢代碼等導致的普遍性能下降等等。最嚴重的障礙可能是這樣的事實，即在使它們成爲BLOB之後，您將無法對列進行索引。如果這不是一個限制，那麼你將不得不測試和測量性能影響。

的數據建模的擔憂等紛紛上調是總體有效，但據我所知，往往在現實世界的理論只能在理論上...

來源

2011-02-02 18:51:54

下面是我給另一個男人誰想要同樣的答案無端表：

Database alternative to MySQL made for millions of TABLES

即上述位是小於優化設計任何關係的數據存儲。 Pop進入數據庫的黃鼠狼：選擇一個你可能會得到你想要的數據。

也許一個沒有sql的解決方案會更好，所以你可以擁有動態數據而不用擔心列限制。

我認爲，如果我們要回答問題，那麼我認爲我們應該提供最佳/更好的做法，當有壞的設計交替出現時。

想以後你來的傢伙作爲KM以上

來源

2014-08-14 22:37:03 Tab

說，以我的經驗並不多2000個字符長的領域最終雖然索引。我認爲使用nvarchar（max）比一些任意長度更好，如果數據不夠長，您可能必須截斷數據。

我看到的一個例子是一個錯誤日誌表，其中表設計者沒有準備將調用堆棧存儲在nvarchar（max）字段中，所以他們存儲了前n個字符，導致截斷的調用堆棧最有趣的部分缺失。

來源

2016-06-07 13:44:45 Cato

SqlServer和nvarchar（最大）

回答

相關問題