Czy są jakieś wady używania VARCHAR (MAX) w tabeli?

Question

Oto moje kłopotliwe położenie.

Zasadniczo potrzebuję kolumny w tabeli, aby pomieścić nieznaną długość znaków. Ale byłem ciekawy, czy w Sql Server mogą wystąpić problemy z wydajnością za pomocą VARCHAR (MAX) lub NVARCHAR (MAX) w kolumnie, takich jak: "Tym razem" Potrzebuję tylko przechowywać 3 znaki, a większość czasu potrzebuję tylko zapisz 10 znaków. Ale jest niewielka szansa, że ​​może to być nawet kilka tysięcy znaków w tej kolumnie, a może nawet milion, To jest nieprzewidywalne. Ale mogę zagwarantować, że nie przekroczy limitu 2 GB.

Byłem po prostu ciekawy, czy są jakieś problemy z wydajnością, lub ewentualnie lepsze sposoby rozwiązania tego problemu, jeśli są dostępne.

Answer 1

Dla mnie brzmi to tak, jakbyś zamierzał użyć typu danych varchar (MAX) zgodnie z jego przeznaczeniem.

Gdy dane w typie danych MAX przekraczają 8 KB, używana jest strona z przepełnieniem. SQL Server 2005 automatycznie przypisuje do strony wskaźnik przepełnienia i wie, jak manipulować wierszami danych w taki sam sposób, w jaki manipuluje innymi typami danych.

Dla dalszego czytania, sprawdź Books Online: char and varchar

Answer 2

Nie, varchar (max) dostosowuje się w zależności od wielkości wejścia, więc jest to najbardziej efektywny, jeśli będzie używana szeroko zróżnicowane wejść wielkości.

Answer 3

Niedawno widziałem artykuł o this. Dokumentuje on dość niewielkie opóźnienie wydajności dla varchar (max) w kolumnie varchar (n). Prawdopodobnie nie wystarczy, by zrobić dla ciebie różnicę. Ale jeśli tak, być może możesz użyć oddzielnej tabeli do przechowywania tych kilku dużych bloków tekstu. Twój mały tekst może pozostać w głównym stole, ale możesz dodać pole flagi, aby poinformować cię, aby zajrzeć do nowej tabeli dla dużych.

Answer 4

Nie można tworzyć indeksy na varchar(max) (i nvarchar(max)) kolumny (chociaż mogą być zawarte w nich. Ale kto by to kolumny w indeksie, które mogą dostać się do 2 GB ?!), więc jeśli chcesz, aby szukać na tej wartości , wykonasz skanowanie za każdym razem, chyba że używasz pełnotekstowych indeksów. Pamiętaj też, że każdy projektant raportów lub projektant prezentacji (w sieci lub w inny sposób) musi zakładać, że ktoś może umieścić Encyklopedię w tej kolumnie i zaprojektować wokół niej. Nic nie jest gorsze niż słyszenie "użytkownicy prawdopodobnie nie będą robić X". Jeśli użytkownik może to zrobić, zrobi to. Jeśli użytkownik umieści tome w kolumnie, w pewnym momencie to zrobi. Jeśli nigdy nie powinny, a następnie IMO, bardziej sensowne byłoby zakrywanie rozmiaru kolumny na pewnym rozsądnym poziomie, a jeśli użytkownik spróbuje wprowadzać więcej do tej kolumny, która jest dozwolona, ​​wywołałoby dyskusję, czy powinny one wpisywać tę wartość do ta kolumna w pierwszej kolejności.

Answer 5

Widziałem pewne problemy - w szczególności z funkcjami skalarnymi (ale są one generalnie okropne, zresztą), które zwracają varchar (MAX), a następnie nie są ponownie rzutowane. Na przykład powiedzmy, że masz specjalną funkcję CleanString (somevarcharmax) zwraca varchar (max) i wywołuje ją na varchar (50), ale nie CAST (CleanString (varchar10col) AS varchar (10)) - nieprzyjemne problemy z wydajnością.

Ale zazwyczaj, gdy masz kolumny varchar (max) w tabeli, nie powinieneś masowo wykonywać tych operacji, więc powiedziałbym, że jeśli używasz go odpowiednio do potrzeb danych w tabeli , to jest w porządku.

Answer 6

Crystal Reports 12 (i inne wersje, o ile mi wiadomo) nie obsługuje poprawnie varchar (max) i interpretuje je jako varchar (255), co prowadzi do obcięcia danych w raportach.

Więc jeśli używasz Crystal Reports, jest to wada dla varchar (max).Lub wadą korzystania z Crystal, aby być precyzyjnym.

Patrz:
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