Có nhược điểm nào khi sử dụng VARCHAR (MAX) trong bảng?

Question

Đây là tình trạng khó khăn của tôi.

Về cơ bản, tôi cần một cột trong bảng để lưu giữ độ dài không xác định của các ký tự. Nhưng tôi đã tò mò nếu trong các vấn đề hiệu suất của Sql Server có thể phát sinh bằng cách sử dụng VARCHAR (MAX) hoặc NVARCHAR (MAX) trong một cột, chẳng hạn như: 'Lần này' tôi chỉ cần lưu 3 ký tự và phần lớn thời gian tôi chỉ cần lưu trữ 10 ký tự. Nhưng có một cơ hội nhỏ có thể lên đến vài nghìn ký tự trong cột đó, hoặc thậm chí có thể là một triệu, Đó là điều không thể đoán trước. Nhưng, tôi có thể đảm bảo rằng nó sẽ không vượt quá giới hạn 2GB.

Tôi chỉ tò mò nếu có bất kỳ vấn đề về hiệu suất nào hoặc có thể là cách tốt hơn để giải quyết vấn đề này nếu có.

Answer 1

Âm thanh với tôi như bạn dự định sử dụng loại dữ liệu VARCHAR (MAX) cho mục đích đã định.

Khi dữ liệu trong loại dữ liệu MAX vượt quá 8 KB, một trang quá dòng được sử dụng. SQL Server 2005 tự động gán một chỉ báo quá dòng cho trang và biết cách thao tác các hàng dữ liệu giống như cách nó thao tác với các kiểu dữ liệu khác.

Để đọc thêm, hãy kiểm tra sách trực tuyến: char and varchar

Answer 2

Không, varchar (max) điều chỉnh bản thân dựa trên kích thước của các mục nhập, vì vậy nó là hiệu quả nhất nếu bạn sẽ sử dụng đầu vào có kích thước đa dạng rộng rãi.

Answer 3

Tôi vừa xem this bài viết vào một ngày khác. Nó tài liệu một độ trễ hiệu suất khá nhỏ cho varchar (max) trên một cột varchar (n). Có lẽ không đủ để tạo sự khác biệt cho bạn. Nhưng nếu có, có lẽ bạn có thể sử dụng một bảng riêng để lưu trữ vài khối văn bản lớn đó. Văn bản nhỏ của bạn có thể nằm trong bảng chính, nhưng bạn có thể thêm một trường cờ để cho bạn biết tìm trong bảng mới cho những cái lớn.

Answer 4

Bạn không thể tạo chỉ mục trên các cột varchar(max) (và nvarchar(max)) (mặc dù chúng có thể được bao gồm trong chúng. Nhưng ai sẽ bao gồm cột trong chỉ mục có thể lên tới 2GB ?!) vì vậy nếu bạn muốn tìm kiếm giá trị này , bạn sẽ thực hiện quét mỗi lần trừ khi bạn sử dụng chỉ mục toàn văn. Ngoài ra, hãy nhớ rằng bất kỳ nhà thiết kế báo cáo hoặc nhà thiết kế bản trình bày nào (web hay cách khác) phải giả định rằng ai đó có thể đặt Bách khoa toàn thư vào cột đó và thiết kế xung quanh nó. Không có gì tệ hơn là nghe "người dùng có lẽ sẽ không làm X". Nếu người dùng có thể làm điều đó, họ sẽ làm điều đó. Nếu một người dùng có thể đặt vào một tome vào một cột, tại một số điểm họ sẽ. Nếu họ không bao giờ nên, sau đó IMO, nó có ý nghĩa hơn để giới hạn kích thước cột ở một mức hợp lý và nếu người dùng cố gắng thêm nhiều hơn vào cột đó được cho phép, nó sẽ gợi ý một cuộc thảo luận về việc liệu họ có nên nhập giá trị đó vào cột đó ở nơi đầu tiên.

Answer 5

Tôi đã nhìn thấy một số vấn đề - đặc biệt là với chức năng vô hướng (nhưng thường là khủng khiếp, dù sao) mà trả về varchar (MAX) và sau đó không tái diễn. Ví dụ, nói rằng bạn có một chức năng đặc biệt CleanString (somevarcharmax) trả về varchar (max) và gọi nó trên varchar (50) nhưng không CAST (CleanString (varchar10col) AS varchar (10)) - vấn đề hiệu suất khó chịu. Tuy nhiên, thông thường, khi bạn có các cột VARCHAR (tối đa) trong một bảng, bạn không nên thực hiện các loại hoạt động đó, vì vậy tôi sẽ nói nếu bạn đang sử dụng nó đúng cách cho nhu cầu dữ liệu của bạn trong bảng thì ổn thôi.

Answer 6

Crystal Reports 12 (và các phiên bản khác, theo như tôi biết) không xử lý varchar (tối đa) đúng và diễn giải nó dưới dạng varchar (255) dẫn đến dữ liệu cắt ngắn trong báo cáo.

Vì vậy, nếu bạn đang sử dụng Crystal Reports, đó là một bất lợi đối với varchar (max).Hoặc bất lợi khi sử dụng Crystal, chính xác.

Xem:
http://www.crystalreportsbook.com/Forum/forum_posts.asp?TID=5843&PID=17503
http://michaeltbeeitprof.blogspot.com/2010/05/crystal-xi-and-varcharmax-aka-memo.html