Чому б не використовувати varchar (max)?

Щодо дизайну баз даних, я трохи старий, тому я повністю використовую правильні розміри даних у стовпцях. Однак, переглядаючи базу даних для свого друга, я помітив, що він varchar(max)багато використовував . Тепер моя безпосередня думка полягала в тому, щоб повернути йому його назад і сказати, щоб він змінив це. Але тоді я задумався і не міг придумати поважної причини, щоб він не використовував його (він використовував інструмент типу case для генерації db, якщо вам цікаво).

Я досліджував тему varchar(max)використання, і я не можу придумати жодної вагомої причини, щоб він не використовував її.

Він не використовує стовпці для індексів, програма, яка знаходиться на базі даних, має обмеження на введення, тому вона не дозволить масивні записи в полях.

Будь-яка допомога буде вдячна, щоб допомогти мені змусити його побачити світло :).

Моя відповідь на це - не про використання Макса, а про причину VARCHAR (max) проти TEXT.

У моїй книзі; Перш за все, якщо ви не будете абсолютно впевнені, що ніколи не кодуєте нічого, крім англійського тексту, і люди не будуть посилатися на імена іноземних місць, тоді вам слід використовувати NVARCHAR або NTEXT.

По-друге, це те, що дозволяють вам робити поля.

ТЕКСТ важко оновити в порівнянні з VARCHAR, але ви отримуєте перевагу повнотекстової індексації та безлічі розумних речей.

З іншого боку, VARCHAR (MAX) має певну неоднозначність, якщо розмір комірки <8000 символів, це буде трактуватися як дані рядка. Якщо воно більше, воно буде розглядатися як LOB для зберігання. Оскільки ви не можете цього знати без запиту RBAR, це може мати стратегії оптимізації для місць, де вам потрібно бути впевненими у своїх даних та скільки це зчитування коштує.

В іншому випадку, якщо ваше використання є відносно буденним, і ви не очікуєте, що у вас виникнуть проблеми з розміром даних (IE, який ви використовуєте .Net, і тому вам не потрібно турбуватися про розмір ваших рядків / символів *) тоді використання VARCHAR (макс.) - це нормально.

Існує повідомлення в блозі про те, чому не використовувати VARCHAR макс тут

Редагувати

Основна відмінність полягає в тому, де зберігаються дані. Рядок даних SQL має максимальний розмір 8000 байт (або він був 8K). Тоді 2 Гб varchar (макс.) Не можна зберігати в рядку даних. SQL Server зберігає його "поза рядом".

Тому ви можете отримати показник продуктивності, оскільки дані не будуть знаходитися в одному місці на диску, див .: http://msdn.microsoft.com/en-us/library/ms189087.aspx

Якщо ви працюєте в середовищі OLTP, ви все про продуктивність. Від накладних витрат та питань налаштування до обмежень індексації та вузьких місць щодо запитів. Використання varcahr (max) або будь-якого іншого типу LOB, швидше за все, суперечить більшості найкращих практик дизайну, тому, якщо не існує конкретної бізнес-потреби, яку неможливо вирішити за допомогою якогось іншого механізму набору тексту, і лише varchar (max) підходить до Тоді, чому тоді піддавати свою систему та додатки таким накладним витратам та продуктивності, які властиві одному з типів даних LOB?

Якщо, з іншого боку, ви працюєте в середовищі OLAP або в середовищі DW Star Schema із таблицями розмірів із полями дескрипторів, які, природно, повинні бути багатослівними, тоді varchar (max), якщо ви не додаєте це до індексу, може бути корисним. Проте я б рекомендував навіть тоді використовувати char (x) varchar (x), оскільки завжди найкращою практикою є використання лише тих ресурсів, які обов’язково повинні бути для виконання роботи.

Їх НЕ слід використовувати, якщо ви не очікуєте великих обсягів даних, і ось причина (безпосередньо від Books Online):

Стовпці, що мають типи даних великого об'єкта (LOB), ntext, text, varchar (max), nvarchar (max), varbinary (max), xml або image не можна вказати як ключові стовпці для індексу.

Якщо ви хочете скалічити продуктивність, використовуйте nvarchar для всього.

Про це Redgate написав чудову статтю.
https://www.red-gate.com/simple-talk/sql/database-administration/whats-the-point-of-using-varcharn-anymore/

Висновки

• Там, де це доречно, використовуйте VARCHAR (n) над VARCHAR (MAX) з міркувань гарного дизайну, якщо не переваги продуктивності, а також тому, що дані VARCHAR (MAX) не стискаються
• Зберігання великих рядків займає більше часу, ніж зберігання маленьких рядків.
• Оновлення значення рядка VARCHAR (MAX) від 8000 до понад 8000 буде відносно повільним, але різниця для однієї транзакції, швидше за все, не буде вимірюваною.
• Оновлення значення рядка VARCHAR (MAX) з понад 8000 до нижче 8000 буде швидшим, ніж якщо таблиця встановлена ​​для зберігання даних поза рядком.
• Використання позарядкової опції для VARCHAR (MAX) спричинить повільнішу запис, поки рядки не стануть дуже довгими.

Я не знаю, як сервер sql обробляє великі (задекларовані) поля varchar з точки зору продуктивності, пам'яті та сховища .. але якщо припустити, що це робиться так само ефективно, як і менші задекларовані поля varchar, все ще існує перевага обмежень цілісності.

Програма, що сидить на базі даних, повинна мати обмеження на вхід, але база даних може належним чином повідомляти про помилку, якщо програма має помилку в цьому відношенні.

Різниця в наступному:
VARCHAR(X)можна індексувати та зберігати у MDF/NDFфайлі даних.
VARCHAR(MAX)неможливо проіндексувати, оскільки може досягати великого обсягу, а потім зберігатиметься як відокремлений файл, а не у MDF/NDFфайлі даних.

   Дещо старомодно вважати, що програма передаватиме лише короткі рядки до бази даних, і це зробить це нормально .

   У наш час ти МАЄШ передбачити, що до бази даних буде отримувати доступ переважно поточна програма, але може існувати майбутня версія програми ((чи знатиме розробник цієї версії тримати рядки менше певної довжини?)

   Ви ПОВИННІ передбачити, що веб-служби, процеси ETL, LYNC to SQL та будь-яка інша кількість вже існуючих та / або ще не існуючих технологій будуть використані для доступу до вашої бази даних.

   Взагалі кажучи, я намагаюся не переходити через varchar (4000), адже це , зрештою , чотири тисячі символів . Якщо я перевищую це значення, тоді я звертаюся до інших типів даних, щоб зберегти все, що я намагаюся зберегти. Брент Озар написав про це досить чудові речі .

   З огляду на це, важливо оцінити підхід поточного проекту до ваших поточних вимог, коли ви працюєте над проектом. Майте уявлення про те, як працюють різні частини, розумійте компроміси різних підходів та вирішуйте проблему. Виконання якоїсь великої аксіоми може призвести до сліпого дотримання, що може перетворити вас на лемінг .