Які наслідки встановлення варчару (8000)?

22

Оскільки varchar займає місце на диску пропорційно розміру поля, чи є якась причина, чому ми не завжди повинні визначати varchar як максимальний, наприклад, varchar(8000)на SQL Server?

Якщо я бачу, що хтось робить, varchar(100)я повинен сказати їм, що ви не помиляєтесь, що слід робити varchar(8000)?

sql-server varchar

— Олександр Левчук
джерело

Я думаю, що ми маємо тут розрізняти використання у створенні таблиці та використання в деклараціях параметрів збережених процедур. Для другого тлумачення дивіться моє запитання dba.stackexchange.com/questions/1772/…

— bernd_k

18

Довжина - це обмеження для даних (наприклад, ПЕРЕВІРТИ, FK, NULL тощо)
Продуктивність, коли рядок перевищує 8060 байт
Не може мати унікальне обмеження або індекс (ширина стовпця ключа повинна бути <900)
За замовчуванням SET ANSI PADDING ON = потенціал для збереження безлічі пробілів
SQL Server передбачає, що середня довжина становить 4000 для операцій сортування, розподіляючи пам’ять на основі цього (потрібно знайти посилання для резервного копіювання, але іржавіє мені, поки я це роблю :-)

Підсумок: не робіть цього.

— гбн
джерело

Продуктивність, коли рядок перевищує 8060 байт . Це стосується фактично використаних байтів, а не максимально дозволених байтів?

— bernd_k

@bernd_k: 8060 = найбільший обсяг даних для одного рядка, який вміститься в одну 8192 сторінку. Включити накладні рядки. Залишок (132 байти) = накладні сторінки

— gbn

Це означає, що продуктивність зменшується, коли більший розмір справді використовується, не з чистого факту, що його використання дозволено.

— bernd_k

@bernd_k: будь-яке зниження продуктивності спричинено 1. розподілом пам'яті для сортів тощо. 2. Переповнення рядків (> 8060 байт). Факт наявності 10 символів у кожному варшарі (8000) не має значення, поки ці умови не будуть виконані (SQL попереджатиме про можливі помилки пізніше для індексних ключів)

— gbn

Чи варто сортувати таблицю зі стовпцем varchar (100), заповненою полями довжиною 100 байт, ще одне питання, оскільки сортування передбачає в середньому 50 символів?

— bernd_k

7

Якщо припустити, що ви посилаєтесь на SQL Server, я можу придумати один.

Існує обмеження розміру (8K) рядка в таблиці, і SQL дозволяє визначати поля varchar, які теоретично можуть перевищувати цю межу. Таким чином, користувач може отримати помилки, якщо він помістить занадто багато даних у поле, пов’язане з цим.

Починаючи з SQL 2K8, ви можете перевищити цю межу, але є наслідки для продуктивності .

Крім того, існує ціла перевірка розумності обмеження розміру на те, як ви очікуєте, щоб вони виглядали. Якщо ви хочете поле без обмеженої довжини, чому б не перейти з текстом або ntext?

— JohnFx
джерело

тому типи даних тексту та ntext зберігаються таким чином, що не впливають на продуктивність?

— Чад

Ці типи не вносять стільки до обмеження розміру 8K рядків у таблиці, оскільки фактичні дані зберігаються в окремій таблиці під обкладинками, а не в рядку з рештою стовпців. Вплив на ефективність все ще є, але з різних причин. Також є обмеження щодо підтримки функцій у цих полях порівняно з varchar та nvarchar

— JohnFx

текст і ntext застаріли на користь varchar (max).

— Філ Хельмер

3

Звичайно, це залежить від того, яка інформація зберігається в полі?

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

Якщо теоретично немає максимальної довжини, я б поставив під сумнів, чому варчар буде використовуватися.

— Тобі
джерело

3

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

При переміщенні даних за допомогою експорту імпорту з бази даних з однобайтовим зіставленням до однієї з множинним байтовим порівнянням (наприклад, Oracle XE) довжина в байтах може збільшуватися, а імпортування даних у таблиці, створені імпортом, не вдається. Звичайно, Oracle має можливість визначити довжину varchar2 або як char, або як байт.

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

Маючи 20% - 100% невикористаного поля, тут є дискусійним варіантом.

— bernd_k
джерело