Có bất kỳ nhược điểm nào khi luôn sử dụng nvarchar (MAX) không?

Trong SQL Server 2005, có bất kỳ nhược điểm nào khi tạo tất cả các trường ký tự nvarchar (MAX) thay vì chỉ định độ dài một cách rõ ràng, ví dụ nvarchar (255) không? (Ngoài một điều hiển nhiên là bạn không thể giới hạn độ dài trường ở cấp cơ sở dữ liệu)

Câu hỏi tương tự đã được hỏi trên Diễn đàn MSDN:

• Varar (tối đa) so với Varchar (255)

Từ bài viết gốc (nhiều thông tin hơn ở đó):

Khi bạn lưu trữ dữ liệu vào cột VARCHAR (N), các giá trị được lưu trữ theo cách vật lý theo cùng một cách. Nhưng khi bạn lưu trữ nó vào cột VARCHAR (MAX), phía sau màn hình, dữ liệu được xử lý dưới dạng giá trị văn bản. Vì vậy, có một số xử lý bổ sung cần thiết khi xử lý giá trị VARCHAR (MAX). (chỉ khi kích thước vượt quá 8000)

VARCHAR (MAX) hoặc NVARCHAR (MAX) được coi là "loại giá trị lớn". Các loại giá trị lớn thường được lưu trữ 'ngoài hàng'. Điều đó có nghĩa là hàng dữ liệu sẽ có một con trỏ đến một vị trí khác nơi 'giá trị lớn' được lưu trữ ...

Đó là một câu hỏi công bằng và anh ấy đã nói rõ hơn

Nhược điểm có thể bao gồm:

Ý nghĩa về hiệu suất Trình tối ưu hóa truy vấn sử dụng kích thước trường để xác định kế hoạch thực hiện hiệu quả nhất

"1. Phân bổ không gian trong phần mở rộng và các trang của cơ sở dữ liệu rất linh hoạt. Do đó, khi thêm thông tin vào trường bằng cập nhật, cơ sở dữ liệu của bạn sẽ phải tạo một con trỏ nếu dữ liệu mới dài hơn dữ liệu được chèn trước đó. trở nên bị phân mảnh = hiệu suất thấp hơn trong hầu hết mọi thứ, từ chỉ mục đến xóa, cập nhật và chèn. " http://sqlblogcasts.com/bloss/simons/archive/2006/02/11/Why-use-anything-but-varchar_2800_max_2900_.aspx

Ý nghĩa tích hợp - khó cho các hệ thống khác biết cách tích hợp với cơ sở dữ liệu của bạn Sự tăng trưởng dữ liệu không thể đoán trước Các sự cố bảo mật có thể xảy ra, ví dụ: bạn có thể làm sập hệ thống bằng cách chiếm hết dung lượng đĩa

Có một bài viết hay ở đây: http://searchsqlserver.techtarget.com/tip/1,289483,sid87_gci1098157,00.html

Dựa trên liên kết được cung cấp trong câu trả lời được chấp nhận, có vẻ như:

1. 100 ký tự được lưu trữ trong một nvarchar(MAX)trường sẽ được lưu trữ không khác với 100 ký tự trong một nvarchar(100)trường - dữ liệu sẽ được lưu trữ nội tuyến và bạn sẽ không có chi phí đọc và ghi dữ liệu 'ngoài luồng'. Vì vậy, không phải lo lắng ở đó.

2. Nếu kích thước lớn hơn 4000, dữ liệu sẽ được lưu trữ tự động 'ngoài hàng', đó là những gì bạn muốn. Vì vậy, không có lo lắng ở đó.

Tuy nhiên...

3. Bạn không thể tạo một chỉ mục trên một nvarchar(MAX)cột. Bạn có thể sử dụng lập chỉ mục toàn văn bản, nhưng bạn không thể tạo một chỉ mục trên cột để cải thiện hiệu suất truy vấn. Đối với tôi, điều này niêm phong thỏa thuận ... đó là một bất lợi nhất định khi luôn sử dụng nvarchar (MAX).

Phần kết luận:

Nếu bạn muốn một loại "độ dài chuỗi phổ quát" trong toàn bộ cơ sở dữ liệu của bạn, có thể được lập chỉ mục và sẽ không lãng phí không gian và thời gian truy cập, thì bạn có thể sử dụng nvarchar(4000).

Đôi khi bạn muốn kiểu dữ liệu thực thi một số ý nghĩa đối với dữ liệu trong đó.

Ví dụ: bạn có một cột thực sự không nên dài hơn 20 ký tự. Nếu bạn xác định cột đó là VARCHAR (MAX), một số ứng dụng giả mạo có thể chèn một chuỗi dài vào đó và bạn sẽ không bao giờ biết hoặc có bất kỳ cách nào để ngăn chặn nó.

Lần tiếp theo ứng dụng của bạn sử dụng chuỗi đó, với giả định rằng độ dài của chuỗi là khiêm tốn và hợp lý cho tên miền mà nó đại diện, bạn sẽ gặp một kết quả không thể đoán trước và khó hiểu.

Tôi đã kiểm tra một số bài viết và tìm tập lệnh kiểm tra hữu ích từ đây: http://www.sqlservercentral.com/Forums/Topic1480639-1292-1.aspx Sau đó thay đổi nó để so sánh giữa NVARCHAR (10) so với NVARCHAR (4000) so với NVARCHAR (MAX) ) và tôi không tìm thấy sự khác biệt về tốc độ khi sử dụng các số được chỉ định nhưng khi sử dụng MAX. Bạn có thể tự kiểm tra. Hy vọng điều này giúp đỡ.

SET NOCOUNT ON;

--===== Test Variable Assignment 1,000,000 times using NVARCHAR(10)
DECLARE @SomeString NVARCHAR(10),
        @StartTime DATETIME;
--=====         
 SELECT @startTime = GETDATE();
 SELECT TOP 1000000
        @SomeString = 'ABC'
   FROM master.sys.all_columns ac1,
        master.sys.all_columns ac2;
 SELECT testTime='10', Duration = DATEDIFF(ms,@StartTime,GETDATE());
GO
--===== Test Variable Assignment 1,000,000 times using NVARCHAR(4000)
DECLARE @SomeString NVARCHAR(4000),
        @StartTime DATETIME;
 SELECT @startTime = GETDATE();
 SELECT TOP 1000000
        @SomeString = 'ABC'
   FROM master.sys.all_columns ac1,
        master.sys.all_columns ac2;
 SELECT testTime='4000', Duration = DATEDIFF(ms,@StartTime,GETDATE());
GO
--===== Test Variable Assignment 1,000,000 times using NVARCHAR(MAX)
DECLARE @SomeString NVARCHAR(MAX),
        @StartTime DATETIME;
 SELECT @startTime = GETDATE();
 SELECT TOP 1000000
        @SomeString = 'ABC'
   FROM master.sys.all_columns ac1,
        master.sys.all_columns ac2;
 SELECT testTime='MAX', Duration = DATEDIFF(ms,@StartTime,GETDATE());
GO

Hãy nghĩ về nó như chỉ là một mức độ an toàn. Bạn có thể thiết kế bảng của mình mà không cần các mối quan hệ khóa ngoài - hoàn toàn hợp lệ - và đảm bảo sự tồn tại của các thực thể liên quan hoàn toàn trên lớp doanh nghiệp. Tuy nhiên, khóa ngoại được coi là thực hành thiết kế tốt vì chúng thêm một mức ràng buộc khác trong trường hợp có gì đó gây rối trên lớp nghiệp vụ. Tương tự như vậy đối với giới hạn kích thước trường và không sử dụng varchar MAX.

Một lý do KHÔNG nên sử dụng các trường tối đa hoặc văn bản là bạn không thể thực hiện việc xây dựng lại chỉ mục trực tuyến tức là REBUILD VỚI ONLINE = ON ngay cả với SQL Server Enterprise Edition.

Vấn đề duy nhất tôi tìm thấy là chúng tôi phát triển các ứng dụng của mình trên SQL Server 2005 và trong một trường hợp, chúng tôi phải hỗ trợ SQL Server 2000. Tôi mới biết, cách khó mà SQL Server 2000 không thích tùy chọn MAX cho varchar hoặc nvarchar.

Ý tưởng tồi khi bạn biết trường sẽ nằm trong một phạm vi được đặt - ví dụ 5 đến 10 ký tự. Tôi nghĩ tôi chỉ sử dụng tối đa nếu tôi không chắc chiều dài sẽ là bao nhiêu. Ví dụ, một số điện thoại sẽ không bao giờ nhiều hơn một số ký tự nhất định.

Bạn có thể thành thật nói rằng bạn không chắc chắn về các yêu cầu về độ dài gần đúng cho mọi trường trong bảng của bạn?

Tôi thực sự hiểu ý của bạn - có một số lĩnh vực tôi chắc chắn sẽ xem xét sử dụng varchar (max).

Điều thú vị là các tài liệu MSDN tổng hợp khá tốt:

Sử dụng varchar khi kích thước của các mục dữ liệu cột thay đổi đáng kể. Sử dụng varchar (max) khi kích thước của các mục nhập dữ liệu cột thay đổi đáng kể và kích thước có thể vượt quá 8.000 byte.

Có một cuộc thảo luận thú vị về vấn đề ở đây .

Công việc của cơ sở dữ liệu là lưu trữ dữ liệu để doanh nghiệp có thể sử dụng. Một phần của việc làm cho dữ liệu đó hữu ích là đảm bảo rằng nó có ý nghĩa. Cho phép ai đó nhập số lượng ký tự không giới hạn cho tên của họ không đảm bảo dữ liệu có ý nghĩa.

Xây dựng các ràng buộc này vào lớp nghiệp vụ là một ý tưởng tốt, nhưng điều đó không đảm bảo rằng cơ sở dữ liệu sẽ vẫn còn nguyên vẹn. Cách duy nhất để đảm bảo rằng các quy tắc dữ liệu không bị vi phạm là thực thi chúng ở mức thấp nhất có thể trong cơ sở dữ liệu.

Một vấn đề là nếu bạn phải làm việc với nhiều phiên bản SQL Server, MAX sẽ không luôn hoạt động. Vì vậy, nếu bạn đang làm việc với DB kế thừa hoặc bất kỳ tình huống nào khác liên quan đến nhiều phiên bản, tốt nhất bạn nên cẩn thận.

Như đã chỉ ra ở trên, nó chủ yếu là sự đánh đổi giữa lưu trữ và hiệu suất. Ít nhất trong hầu hết các trường hợp.

Tuy nhiên, có ít nhất một yếu tố khác cần được xem xét khi chọn n / varchar (Max) trên n / varchar (n). Là dữ liệu sẽ được lập chỉ mục (chẳng hạn như, tên cuối cùng)? Vì định nghĩa MAX được coi là LOB, nên mọi thứ được định nghĩa là MAX đều không có sẵn để lập chỉ mục. và không có chỉ mục, bất kỳ tra cứu nào liên quan đến dữ liệu như vị ngữ trong mệnh đề WHERE sẽ bị buộc phải quét toàn bộ Bảng, đây là hiệu suất tồi tệ nhất bạn có thể nhận được khi tra cứu dữ liệu.

1) Máy chủ SQL sẽ phải sử dụng nhiều tài nguyên hơn (bộ nhớ được phân bổ và thời gian cpu) khi xử lý nvarchar (max) so với nvarchar (n) trong đó n là một số cụ thể cho trường.

2) Điều này có nghĩa gì đối với hiệu suất?

Trên SQL Server 2005, tôi đã truy vấn 13.000 hàng dữ liệu từ một bảng có 15 cột nvarchar (tối đa). Tôi đã hẹn giờ các truy vấn nhiều lần và sau đó thay đổi các cột thành nvarchar (255) hoặc ít hơn.

Các truy vấn trước khi tối ưu hóa trung bình ở mức 2.0858 giây. Các truy vấn sau khi thay đổi trả về trung bình 1,90 giây. Đó là khoảng 184 mili giây cải tiến cho truy vấn select * cơ bản. Đó là một cải tiến 8,8%.

3) Kết quả của tôi là đồng tình với một vài bài báo khác chỉ ra rằng có sự khác biệt về hiệu suất. Tùy thuộc vào cơ sở dữ liệu của bạn và truy vấn, tỷ lệ phần trăm cải thiện có thể khác nhau. Nếu bạn không có nhiều người dùng đồng thời hoặc rất nhiều hồ sơ, thì sự khác biệt về hiệu suất sẽ không phải là vấn đề đối với bạn. Tuy nhiên, sự khác biệt hiệu suất sẽ tăng lên khi nhiều hồ sơ và người dùng đồng thời tăng lên.

Tôi đã có một udf mà đệm chuỗi và đặt đầu ra thành varchar (max). Nếu điều này được sử dụng trực tiếp thay vì chuyển trở lại kích thước phù hợp cho cột được điều chỉnh, hiệu suất rất kém. Cuối cùng tôi đã đặt udf đến một độ dài tùy ý bằng một ghi chú lớn thay vì dựa vào tất cả các người gọi của udf để đúc lại chuỗi thành kích thước nhỏ hơn.

hỗ trợ hệ thống di sản. Nếu bạn có một hệ thống đang sử dụng dữ liệu và dự kiến ​​sẽ có độ dài nhất định thì cơ sở dữ liệu là một nơi tốt để thực thi độ dài. Điều này không lý tưởng nhưng hệ thống di sản đôi khi không lý tưởng. = P

Nếu tất cả các dữ liệu trong một hàng (cho tất cả các cột) sẽ không bao giờ lấy hợp lý 8000 hoặc ít hơn các ký tự thì thiết kế ở lớp dữ liệu sẽ thực thi điều này.

Công cụ cơ sở dữ liệu hiệu quả hơn nhiều khi giữ mọi thứ trong bộ nhớ blob. Càng nhỏ bạn có thể hạn chế một hàng càng tốt. Càng nhiều hàng bạn có thể nhồi nhét trong một trang càng tốt. Cơ sở dữ liệu chỉ hoạt động tốt hơn khi phải truy cập ít trang hơn.

Các thử nghiệm của tôi đã chỉ ra rằng có sự khác biệt khi lựa chọn.

CREATE TABLE t4000 (a NVARCHAR(4000) NULL);

CREATE TABLE tmax (a NVARCHAR(MAX) NULL);

DECLARE @abc4 NVARCHAR(4000) = N'ABC';

INSERT INTO t4000
SELECT TOP 1000000 @abc4
    FROM
    master.sys.all_columns ac1,
    master.sys.all_columns ac2;

DECLARE @abc NVARCHAR(MAX) = N'ABC';

INSERT INTO tmax
SELECT TOP 1000000 @abc
    FROM
    master.sys.all_columns ac1,
    master.sys.all_columns ac2;

SET STATISTICS TIME ON;
SET STATISTICS IO ON;

SELECT * FROM dbo.t4000;
SELECT * FROM dbo.tmax;

Liên kết thú vị: Tại sao nên sử dụng VARCHAR khi bạn có thể sử dụng văn bản?

Đó là về PostgreSQL và MySQL, vì vậy phân tích hiệu suất là khác nhau, nhưng logic cho "nhân chứng" vẫn giữ nguyên: Tại sao buộc bản thân phải luôn lo lắng về điều gì đó có liên quan đến một tỷ lệ nhỏ thời gian? Nếu bạn đã lưu địa chỉ email vào một biến, bạn sẽ sử dụng 'chuỗi' không phải là 'chuỗi giới hạn trong 80 ký tự'.

Nhược điểm chính tôi có thể thấy là hãy nói rằng bạn có điều này:

Cái nào cung cấp cho bạn nhiều thông tin nhất về dữ liệu cần thiết cho UI?

Điều này

            CREATE TABLE [dbo].[BusData](
                [ID] [int] IDENTITY(1,1) NOT NULL,
                [RecordId] [nvarchar](MAX) NULL,
                [CompanyName] [nvarchar](MAX) NOT NULL,
                [FirstName] [nvarchar](MAX) NOT NULL,
                [LastName] [nvarchar](MAX) NOT NULL,
                [ADDRESS] [nvarchar](MAX) NOT NULL,
                [CITY] [nvarchar](MAX) NOT NULL,
                [County] [nvarchar](MAX) NOT NULL,
                [STATE] [nvarchar](MAX) NOT NULL,
                [ZIP] [nvarchar](MAX) NOT NULL,
                [PHONE] [nvarchar](MAX) NOT NULL,
                [COUNTRY] [nvarchar](MAX) NOT NULL,
                [NPA] [nvarchar](MAX) NULL,
                [NXX] [nvarchar](MAX) NULL,
                [XXXX] [nvarchar](MAX) NULL,
                [CurrentRecord] [nvarchar](MAX) NULL,
                [TotalCount] [nvarchar](MAX) NULL,
                [Status] [int] NOT NULL,
                [ChangeDate] [datetime] NOT NULL
            ) ON [PRIMARY]

Hay cái này?

            CREATE TABLE [dbo].[BusData](
                [ID] [int] IDENTITY(1,1) NOT NULL,
                [RecordId] [nvarchar](50) NULL,
                [CompanyName] [nvarchar](50) NOT NULL,
                [FirstName] [nvarchar](50) NOT NULL,
                [LastName] [nvarchar](50) NOT NULL,
                [ADDRESS] [nvarchar](50) NOT NULL,
                [CITY] [nvarchar](50) NOT NULL,
                [County] [nvarchar](50) NOT NULL,
                [STATE] [nvarchar](2) NOT NULL,
                [ZIP] [nvarchar](16) NOT NULL,
                [PHONE] [nvarchar](18) NOT NULL,
                [COUNTRY] [nvarchar](50) NOT NULL,
                [NPA] [nvarchar](3) NULL,
                [NXX] [nvarchar](3) NULL,
                [XXXX] [nvarchar](4) NULL,
                [CurrentRecord] [nvarchar](50) NULL,
                [TotalCount] [nvarchar](50) NULL,
                [Status] [int] NOT NULL,
                [ChangeDate] [datetime] NOT NULL
            ) ON [PRIMARY]

Một nhược điểm là bạn sẽ thiết kế xung quanh một biến không thể đoán trước và có thể bạn sẽ bỏ qua thay vì tận dụng cấu trúc dữ liệu SQL Server nội bộ, dần dần được tạo thành từ Row (s), Page (s) và Extent (s).

Điều này khiến tôi suy nghĩ về sự liên kết cấu trúc dữ liệu trong C và việc nhận thức được sự liên kết thường được coi là một điều tốt (TM). Ý tưởng tương tự, bối cảnh khác nhau.

Trang MSDN cho Trang và Phạm vi

Trang MSDN cho dữ liệu tràn hàng

Đầu tiên tôi nghĩ về điều này, nhưng sau đó lại nghĩ. Có ý nghĩa về hiệu suất, nhưng đồng thời nó cũng đóng vai trò là một dạng tài liệu để có ý tưởng về kích thước của các trường thực sự. Và nó thực thi khi cơ sở dữ liệu đó nằm trong một hệ sinh thái lớn hơn. Theo tôi, chìa khóa là được cho phép nhưng chỉ trong phạm vi lý do.

ok, đây là cảm xúc của tôi đơn giản về vấn đề kinh doanh và logic lớp dữ liệu. Điều này phụ thuộc, nếu DB của bạn là tài nguyên được chia sẻ giữa các hệ thống chia sẻ logic kinh doanh thì tất nhiên đó có vẻ là một nơi tự nhiên để thực thi logic đó, nhưng đó không phải là cách TỐT NHẤT để làm điều đó, cách TỐT NHẤT là cung cấp API, điều này cho phép sự tương tác được kiểm tra và giữ logic kinh doanh ở nơi nó thuộc về, nó giữ cho các hệ thống được tách rời, nó giữ cho các tầng của bạn trong một hệ thống được tách rời. Tuy nhiên, nếu cơ sở dữ liệu của bạn được cho là chỉ phục vụ một ứng dụng, thì hãy suy nghĩ về AGILE, điều gì là sự thật? thiết kế cho bây giờ. Nếu và khi cần truy cập như vậy, hãy cung cấp API cho dữ liệu đó.

rõ ràng, đây chỉ là lý tưởng, nếu bạn đang làm việc với một hệ thống hiện có thì khả năng là bạn sẽ cần phải làm điều đó khác đi ít nhất là trong thời gian ngắn.

Điều này sẽ gây ra vấn đề về hiệu năng, mặc dù nó có thể không bao giờ gây ra bất kỳ vấn đề thực tế nào nếu cơ sở dữ liệu của bạn nhỏ. Mỗi bản ghi sẽ chiếm nhiều dung lượng hơn trên ổ cứng và cơ sở dữ liệu sẽ cần đọc thêm các phần của đĩa nếu bạn đang tìm kiếm thông qua nhiều bản ghi cùng một lúc. Ví dụ: một bản ghi nhỏ có thể vừa với 50 cho một khu vực và một bản ghi lớn có thể phù hợp với 5. Bạn cần đọc gấp 10 lần dữ liệu từ đĩa bằng cách sử dụng bản ghi lớn.

Nó sẽ làm cho thiết kế màn hình trở nên khó khăn hơn vì bạn sẽ không còn có thể dự đoán độ rộng của điều khiển của bạn.