Почему n в varchar (n) следует указывать как конкретную цифру?

Question

Я перечитал это и не мог ясно понять ...

Имея (с целью сокращения этого вопроса)

DECLARE @temp VARCHAR(4001); 
--update: 4001 is for example only to avoid varchar(MAX) discussions
-- I am aware about 8000 
SET @temp = 'a';  

SQL Server резервирует 4001 байт для @temp, который (остальные 4000 из 4001 байтов @temp) нельзя использовать для ЛЮБЫХ других целей, пока @temp не будет удален?

Если этого не произойдет, то (обновление: извините, это был вопрос риторики, я думаю, что это не изменило смысла моих вопросов):

• Почему SQL Server должен знать максимальный размер значений varchar?
• Почему строка размером больше 4001 байта не может быть (пере) назначена @temp?
  обновление: если 4001 байт не выделено заранее или не зарезервировано для @ temp
• Как SQL Server использует этот размер?

Те же вопросы о таблице, содержащей один столбец varchar (4001).
Как мне назвать 4001 в varchar (4001), чтобы избежать двусмысленности с varchar (max)?
то есть избегать привлечения "максимального" слова.

[1], например, намекает, что это размер столбца:

Тип данных varchar является типом данных переменной длины. Значения короче размера столбца ... [1]

чтобы я мог понять , что этот размер зарезервирован, столбец имеет фиксированный размер (по всем строкам), независимо от более коротких значений, хранящихся там.
Правильно? Если не правильно, то Каков размер столбца varchar (4001), используя терминологию из [1]?

Обновление
Я хотел (указав 4001) избегать отклонения этой темы от хранения значений в строке (например, SQL Server varchar (max), text и т. Д.), А также других тем, которые здесь специально не задавались.

Вопрос не в том, как использовать n в varchar (n), а в том, как его использовать (SQL Server).

Я приветствую других специалистов по СУБД, так как это должны быть вопросы, не связанные с DBМS, хотя конкретные цифры указаны в контексте SQL Server 2000 (или 2005+ без varchar (MAX))

Update2
Размер префикса длины для хранения данных таблицы в SQL Server всегда равен 2 согласно [2]. Почему бы просто не использовать varchar (), чтобы SQL Server работал с реальным размером?
Кроме того, я (намеренно) основал свой вопрос на переменной.
Также, введенная цифра действительно усекает хранилище / данные:

DECLARE @temp VARCHAR(2); 
SET @temp = 'aaaaaa';
select @temp
 -- result is: aa

[1]
msdn "Использование данных char и varchar"
http://msdn.microsoft.com/en-us/library/ms175055.aspx
[2]
Оценка размера кучи
http://msdn.microsoft.com/en-us/library/ms189124.aspx

Answer 1

Как используется n в varchar (n)?

Это зависит от реализации.

В SQLite , n полностьюигнорируется.

В PostgreSQL , varchar(n) по существу эквивалентен TEXT с ограничением CHECK (LENGTH(TheColumn) <= n).Указание максимального размера не дает никакого преимущества в производительности.

В MySQL , n определяет размер префикса длины, поэтому VARCHAR(255) использует 1 байт для хранения длины иVARCHAR(65535) использует 2 байта.

Для MS SQL Server см. Вопрос [Почему бы не использовать] varchar (max) везде?

Answer 2

Зачем назначать tinyint или целое число?Если ваши данные для одного данного столбца имеют 15 дискретных значений, то, очевидно, tinyint.

То же самое относится и к varchar: он сообщает SQL Server, какие значения / длины ожидаются в этом столбце.SQL Server выдает ошибку, если данные будут усечены.

Вы можете применить один и тот же аргумент к NULL / NOT NULL, или к внешним ключам, или к ограничениям CHECK и т. Д.: Все они используются для обеспечения правильности ваших данных.См. " Декларативная ссылочная целостность ".

Например, я бы хотел запретить кому-либо пытаться сохранить 500 КБ XMl в моем текстовом столбце с 100-байтовым именем, потому что они могут.Если кто-то преуспел, как вы думаете, что произойдет с другими клиентами, которые ожидали максимум 100 байт?

Это также важно для эффективности хранения.Можно объявить «String» для объекта ac #, который вы можете создать, использовать, удалить и оставить в памяти (в основном) на короткое время.Сохранение миллиарда строк «строки» - это ненужные накладные расходы.

Можно пойти дальше и спросить, зачем использовать varchar? Почему бы не использовать nvarchar везде? Опять же, у меня есть таблица, в которой хранится код валюты с приближением к миллиарду строк.nchar (3) против char (3) стоит мне 3 ГБ дополнительного хранилища (+ индексы + изменения длины строк).

Резюме: это ограничение ваших данных.