Я не решаюсь добавить еще один ответ здесь, поскольку их уже немало, но необходимо сделать несколько замечаний, которые либо не были сделаны, либо не были сделаны четко.
Первый: Делать Не всегда использовать NVARCHAR. Это очень опасный и часто дорогостоящий подход / подход. И не лучше сказать « Никогда использовать курсоры», поскольку они иногда являются наиболее эффективным средством решения конкретной проблемы, и общий обходной цикл WHILE почти всегда будет медленнее чем правильно готово Курсор.
Единственный раз, когда вы должны использовать термин «всегда», это когда вы советуете «всегда делать то, что лучше для ситуации». Конечно, это часто трудно определить, особенно когда мы пытаемся сбалансировать краткосрочные выгоды во времени разработки (менеджер: «нам нужна эта функция, о которой вы не знали до сих пор - неделю назад!») С давно расходы на техническое обслуживание (менеджер, который первоначально заставил команду завершить трехмесячный проект в трехнедельном спринте: «почему у нас возникают такие проблемы с производительностью? как мы могли бы сделать X, у которого нет гибкости? один-два спринта, чтобы это исправить. Что мы можем сделать за неделю, чтобы вернуться к приоритетным задачам? И нам определенно нужно больше времени уделять дизайну, чтобы этого не происходило! »).
Второе: @ Ответ gbn затрагивает некоторые очень важные моменты, которые следует учитывать при принятии определенных решений по моделированию данных, когда путь не ясен на 100%. Но есть еще что рассмотреть:
- размер файлов журнала транзакций
- время, необходимое для репликации (при использовании репликации)
- время, необходимое для ETL (если ETLing)
- время, необходимое для отправки журналов в удаленную систему и восстановления (если используется доставка журналов)
- размер резервных копий
- время, необходимое для завершения резервного копирования
- длительность восстановления (это может быть важно когда-нибудь; -)
- размер, необходимый для tempdb
- производительность триггеров (для вставленных и удаленных таблиц, которые хранятся в базе данных tempdb)
- производительность версионирования строк (если используется SNAPSHOT ISOLATION, поскольку хранилище версий находится в базе данных tempdb)
- возможность получить новое дисковое пространство, когда финансовый директор говорит, что они только что потратили 1 миллион долларов на SAN в прошлом году, и поэтому они не будут выделять еще 250 тысяч долларов на дополнительное хранилище
- длительность выполнения операций INSERT и UPDATE
- время, необходимое для обслуживания индекса
- и т. Д. И т. П.
Потеря пространства имеет огромный каскадный эффект на всю систему. Я написал статью, подробно описав эту тему: Диск дешев! ORLY? (требуется бесплатная регистрация; извините, я не контролирую эту политику).
Третье: Хотя некоторые ответы неправильно фокусируются на аспекте «это маленькое приложение», а некоторые правильно предлагают «использовать то, что подходит», ни один из ответов не дал реального руководства для ОП Важной деталью, упомянутой в Вопросе, является то, что это веб-страница для их школы. Большой! Таким образом, мы можем предложить, что:
- Поля для имен студентов и / или преподавателей должны , вероятно, быть
NVARCHAR, поскольку со временем становится все более вероятным, что имена из других культур будут появляться в этих местах.
- Но для адреса и названия города? Цель приложения не была указана (это было бы полезно), но при условии, что адресные записи, если таковые имеются, относятся только к определенному географическому региону (т. Е. К одному языку / культуре), затем используйте
VARCHAR с соответствующим кодом Страница (которая определяется из сопоставления поля). - Если хранятся коды ISO штата и / или страны (не нужно хранить
INT / TINYINT, поскольку коды ISO имеют фиксированную длину, удобочитаемы и, что ж, стандартны :), используйте CHAR(2) для двухбуквенных кодов и CHAR(3) при использовании трехбуквенных кодов. И подумайте об использовании двоичного сопоставления, такого как Latin1_General_100_BIN2.
- При хранении почтовых индексов (то есть почтовых индексов) используйте
VARCHAR, поскольку это международный стандарт, запрещающий использование букв за пределами A-Z. И да, по-прежнему используйте VARCHAR, даже если хранятся только почтовые индексы США, а не INT, поскольку почтовые индексы не являются числами, они являются строками, и некоторые из них имеют начальный «0». И рассмотрите возможность использования двоичной сортировки, такой как Latin1_General_100_BIN2.
- При хранении адресов электронной почты и / или URL-адресов используйте
NVARCHAR, поскольку теперь оба они могут содержать символы Юникода.
- и т. Д.
Четвертый: Теперь, когда у вас есть NVARCHAR данные, занимающие вдвое больше места, чем нужно для данных, которые хорошо вписываются в VARCHAR ("хорошо вписывается" = не превращается в " ? ") и каким-то образом, как по волшебству, приложение действительно выросло, и теперь миллионы записей есть по крайней мере в одном из этих полей, где большинство строк являются стандартными ASCII, но некоторые содержат символы Юникода, поэтому вам придется сохранить NVARCHAR, учтите следующее:
Если вы используете SQL Server 2008 - 2016 RTM и для Enterprise Edition, ИЛИ если вы используете SQL Server 2016 SP1 (который сделал сжатие данных доступным во всех выпусках) или новее, то вы можно включить Сжатие данных . Сжатие данных может (но не всегда) сжимать данные Unicode в полях NCHAR и NVARCHAR. Определяющими факторами являются:
NCHAR(1 - 4000) и NVARCHAR(1 - 4000) используют стандартную схему сжатия для Unicode , но только начиная с SQL Server 2008 R2, И только для данных IN ROW, а не OVERFLOW! Это выглядит лучше, чем обычный алгоритм сжатия ROW / PAGE. NVARCHAR(MAX) и XML (и я предполагаю также, что VARBINARY(MAX), TEXT и NTEXT) данные, которые находятся в строке (не в строке на страницах LOB или OVERFLOW), по крайней мере, могут быть сжаты PAGE, но не ROW сжатый. Конечно, сжатие PAGE зависит от размера значения в строке: я протестировал VARCHAR (MAX) и увидел, что 6000 строк символов / байтов не будут сжиматься, а 4000 строк символов / байтов - - Любые данные OFF ROW, LOB или OVERLOW = Нет сжатия для вас!
При использовании SQL Server 2005 или RTM 2008 - 2016 и не в Enterprise Edition вы можете иметь два поля: одно VARCHAR и одно NVARCHAR. Например, предположим, что вы храните URL-адреса, которые в основном все являются базовыми символами ASCII (значения 0–127) и, следовательно, вписываются в VARCHAR, но иногда содержат символы Unicode. Ваша схема может содержать следующие 3 поля:
...
URLa VARCHAR(2048) NULL,
URLu NVARCHAR(2048) NULL,
URL AS (ISNULL(CONVERT(NVARCHAR([URLa])), [URLu])),
CONSTRAINT [CK_TableName_OneUrlMax] CHECK (
([URLa] IS NOT NULL OR [URLu] IS NOT NULL)
AND ([URLa] IS NULL OR [URLu] IS NULL))
);
В этой модели вы только ВЫБЕРИТЕ из вычисляемого столбца [URL]. Для вставки и обновления вы определяете, какое поле использовать, видя, изменяет ли преобразование входящее значение, которое должно иметь тип NVARCHAR:
INSERT INTO TableName (..., URLa, URLu)
VALUES (...,
IIF (CONVERT(VARCHAR(2048), @URL) = @URL, @URL, NULL),
IIF (CONVERT(VARCHAR(2048), @URL) <> @URL, NULL, @URL)
);
Вы можете записать входящие значения в VARBINARY(MAX) и затем разархивировать при выходе:
- Для SQL Server 2005 - 2014: вы можете использовать SQLCLR. SQL # (библиотека SQLCLR, которую я написал) поставляется с Util_GZip и Util_GUnzip в бесплатной версии
- Для SQL Server 2016 и новее: вы можете использовать встроенные функции
COMPRESS и DECOMPRESS, которые также являются GZip.
Если вы используете SQL Server 2017 или новее, вы можете сделать таблицу Clustered Columnstore Index.
Хотя этот вариант пока не подходит, в SQL Server 2019 появилась встроенная поддержка UTF-8 в типах данных VARCHAR / CHAR. В настоящее время в нем слишком много ошибок, чтобы его можно было использовать, но если они исправлены, то это вариант для некоторых сценариев. Пожалуйста, смотрите мой пост " Собственная поддержка UTF-8 в SQL Server 2019: Спаситель или Лжепророк? " для подробного анализа этой новой функции.