В столбце изменения SQL Server varchar (255) nvarchar
Я использую экспресс SQL-сервера 2008, и некоторые наши столбцы определяются как varchar (255). Я должен преобразовать эти столбцы в NvarChar (255) или nvarchar (макс.)?
Причина, которую я спрашиваю, я считал, что nvarchar (255) для unicode символов на самом деле сохранит 1/2 количество символов (так как unicode символы составляют 2 байта), тогда как 255 с varchar () позволил бы мне хранить 255 символов (или это 255 - 2 для смещения).
Были бы какие-либо хиты производительности с помощью nvarchar (макс.)?
JDs
2 ответа
Ну, не совсем так - преобразование в NVarChar (255) не сокращает количество хранимых символов вдвое - он по-прежнему хранит 255 символов. Просто ему нужно вдвое больше места (510 байт против 255 байт).
Вам следует преобразовать в NVARCHAR - даже если он все время использует вдвое больше места - если вам:
- нужно поддерживать арабский, иврит, кириллицу или любой из восточноазиатских языков - только в Unicode вы будете способный фактически захватывать эти символы
- , необходимо поддерживать другие языки, которые используют «стандартный» латинский алфавит, но имеют специальные символы - например, восточноевропейские (славянские) языки с их символами, такими как
č ă ě- они будут сохранены какc, a, eв поле varchar ()
NVarchar (max) - отличный вариант - если вам действительно требуется до 2 ГБ текст. Сделать все строковые поля nvarchar (max) просто «непротиворечивыми» - это действительно плохая идея - у вас возникнут серьезные проблемы с производительностью. См. Статью Ремуса Русану по теме
У вас должно быть какое-то обоснование для каждого типа данных, который вы используете.
nvarchar (255) (в SQL Server) хранит 255 символов Unicode (в 510 байтах плюс накладные расходы).
Конечно, можно хранить обычные данные Unicode в кодировке UTF-8 в столбцах varchar - по одному символу varchar на байт в источнике (UTF-8 будет использовать несколько байтов соответственно для широких символов). В этом случае обычные данные ASCII используют только 1 байт на символ, поэтому у вас нет двухбайтовых накладных расходов. У него много недостатков, не в последнюю очередь из-за того, что база данных больше не может так сильно помогать с сопоставлением и другими манипуляциями с символами, поскольку данные потенциально закодированы. Но, как я уже сказал, это возможно.
Я рекомендую символы char или varchar соответствующей длины для таких вещей, как номера счетов, где десятичное число может не использоваться, потому что заполнение нулями имеет значение, номера лицензий, номера счетов (с буквами), почтовые индексы, номера телефонов и т. Д. типы столбцов, которые НИКОГДА не содержат широких символов и обычно ограничиваются только латинскими буквами и цифрами, иногда даже без знаков препинания, и часто сильно индексируются. Абсолютно нет необходимости в накладных расходах дополнительных старших байтов NUL для всех этих символов в столбцах как в таблицах, так и в индексах и в рабочем наборе в ядре базы данных.
Я рекомендую nvarchar для таких вещей, как имена, адреса и т. Д., Где возможны широкие символы, возможно, даже если в ближайшем будущем его использование не ожидается.
Обычно я никогда не использую nchar - мне никогда не нужны были короткие коды (обычно в тех случаях, когда я выбирал столбцы типа char), которые требовали широких символов.
Во всех случаях действительно следует тщательно продумать использование длины (или максимальной) длины. Я бы определенно не стал использовать max для имен или адресов, и при тестировании могут быть очевидны накладные расходы. Я видел, как приведение к varchar (length) на промежуточных этапах запросов резко повышает производительность.