Как значения varchar хранятся в базе данных SQL Server?

Question

У моего коллеги-программиста есть странное требование от руководителя его команды;он настаивал на создании varchar столбцов длиной 16 * 2 ⁿ .

Какой смысл такого ограничения?

Могу предположить, что короткие строки (например, менее 128 символов) хранится непосредственно в записи таблицы, и с этой точки зрения ограничение поможет выровнять поля в записи, более крупные строки хранятся в базе данных «куча» и только ссылка на эту строкусохраняется в записи таблицы.

Так ли это?

Имеет ли это требование достаточные основания?

Кстати, СУБД - SQL Server 2008.

Answer 1

Полностью бессмысленное ограничение, насколько я вижу. Предполагая стандартный формат FixedVar (в отличие от форматов, используемых для сжатия строк / страниц или разреженных столбцов) и предполагая, что речь идет о varchar(1-8000) столбцах

Все varchar данные хранятся в конце строки в секции переменной длины (или на страницах offrow, если они не могут поместиться в строке). Объем пространства, которое он использует в этом разделе (и не зависит ли он от строки), полностью зависит от длины фактических данных, а не от объявления столбца.

SQL Server будет использовать длину, объявленную в объявлении столбца при выделении памяти (например, для sort операций). В этом случае предполагается, что varchar столбцы будут заполнены на до 50% их объявленного размера в среднем , поэтому при выборе размера лучше взглянуть на это.

Answer 2

Я слышал об этой практике раньше, но после небольшого исследования этого вопроса я не думаю, что есть практическая причина для того, чтобы значения varchar были кратны 16. Я думаю, что это требование, вероятно, связано с попыткой оптимизировать используемое пространство. на каждой странице. В SQL Server страницы установлены по 8 КБ на страницу. Строки хранятся в страницах, поэтому, возможно, вы думаете, что вы можете сэкономить место на страницах, если размер каждой строки разделить равномерно на 8 КБ (более подробное описание того, как SQL Server хранит данные, можно найти здесь ). Однако, поскольку объем пространства, используемого полем varchar, определяется его фактическим содержимым, я не вижу, как использование длин, кратных 16, или любой другой схемы может помочь вам оптимизировать объем пространства, используемого каждой строкой на странице , Длина полей varchar должна быть установлена ​​в соответствии с требованиями бизнеса.

Кроме того, этот вопрос охватывает аналогичное обоснование, и вывод также выглядит аналогичным:
Размеры столбцов базы данных для символьных данных

Answer 3

Вы всегда должны хранить данные в размере данных, который соответствует хранимым данным. Это часть того, как база данных может поддерживать целостность. Например, предположим, что вы храните адреса электронной почты. Если ваш размер данных равен максимально допустимому адресу электронной почты, вы не сможете хранить неверные данные, которые больше этого размера. Это хорошая вещь. Некоторые люди хотят сделать все nvarchar (max) или varchar (max). Однако это вызывает только проблемы с индексацией.

Лично я бы вернулся к человеку, который сделал это требование, и спросил бы причину. Тогда я бы изложил свои причины относительно того, почему это не может быть хорошей идеей. Я никогда не буду слепо реализовывать что-то подобное. Возвращаясь к требованию, подобному этому, я сначала проведу некоторое исследование того, как SQL Server организует данные на диске, чтобы показать, какое влияние это требование может оказать на производительность. Я мог бы даже удивиться, узнав, что требование имело смысл, но я сомневаюсь в этом на данный момент.