производительность nchar vs nvarchar

Question

Как вы решили, использовать ли nvarchar или nchar?

Например, я заметил, что база данных членства по умолчанию, созданная провайдером sqlmembership, объявляет столбец Email типом nvarchar (256)

Мне кажется, это слишком большое максимальное значение для столбца электронной почты. Я подозреваю, что в обычных условиях электронные письма длиннее 40 или 50 символов будут довольно редкими.

Но так как данные, такие как адреса электронной почты, различаются по длине, должны ли они всегда храниться как nvarchar, чтобы исключить избыточное пространство?

При использовании nvarchar для столбца электронной почты. В случае изменения адреса электронной почты, если новый адрес электронной почты будет длиннее предыдущего, это вызовет много разрывов страниц и, как следствие, значительную потерю производительности?

Рассматривали ли бы вы когда-нибудь использование nchar (40) для адреса электронной почты и компромиссную потерю места для хранения в обмен на снижение производительности без разделения страницы?

Или использование nchar (40) значительно увеличит размер базы данных, что приведет к другим сбоям в производительности по скорости запросов?

Разумно ли следовать правилу nchar, если вы знаете размер данных для заполнения столбца?

Answer 1

письма длиной более 40 или 50 символов были бы довольно редкими

Требуется только один, чтобы испортить вашу модель ...

если новое письмобольше, чем предыдущий адрес электронной почты, это вызовет много разделений страницы

Нет.Но даже если бы это было так, вы не спроектировали свою модель данных.Допустим, ради аргумента, что каждый раз, когда электронное письмо обновляется, оно вызывает разделение страницы.Вы бы оптимизировали для , что ?Нет, поскольку предварительное выделение большого фиксированного размера (т. Е. С использованием NCHAR (256)) намного хуже, это действительно устраняет потенциальное разбиение страницы при обновлении (опять же, если такое разбиение страницы произойдет ) но при гораздо худших затратах на увеличение размера таблицы, что приводит к пропускной способности ввода-вывода и потреблению памяти, см. Дисковое пространство дешево ... ЭТО НЕ ТОЧКА !!! .

Почему я говорю, что обновления переменной длины не вызывают разбиение страницы?Потому что разделение страниц происходит принудительно, когда изображение строки больше не помещается на странице.Обновление столбца переменной длины, вероятно, вызовет переполнение строки и оставит строку того же размера, что и раньше, или даже меньше.В некоторых случаях после переполнения строка будет увеличиваться в размере, но есть несколько условий, чтобы это фактически вызвало разделение страницы:

• обновление значения должно вызывать увеличение размера строки, это может толькопроисходит при обновлении со значения, меньшего, чем 24-байтовый указатель, описанный в Организация таблиц и индексов , до значения, большего, чем этот размер указателя.
• увеличение размера строки (что по определениюувеличение не более чем на 24 байта для каждого обновляемого столбца переменной, включая обновления с NULL на не-NULL), должно привести к появлению строки, которая не помещается на странице.
• не должно быть возможного освобождения пространства встрока из толкающих других полей вне строки (то есть все поля переменной длины уже сдвинуты вне строки)

Я действительно не покупаю, что у вас есть такой странный иЭзотерическая нагрузка, как условия выше, должна быть главным фактором в управлении вашим дизайном.Используйте NVARCHAR удобной длины, чтобы приспособиться к любому значению, с которым вы столкнетесь.