Эрго: при разработке баз данных SQL Server сегодня всегда нужно использовать NVARCHAR.
Является ли это рассуждение звуком? Кто-нибудь не согласен с каким-либо из помещений? Есть ли какие-либо причины для выбора VARCHAR по сравнению с NVARCHAR сегодня?
Вы сопоставляете тип данных с данными, которые будут храниться в столбце. По аналогичному аргументу вы могли бы сказать, почему не хранить все данные в столбцах NVARCHAR, потому что числа и даты могут быть представлены в виде строк цифр.
Если наилучшее соответствие для данных, которые будут храниться в столбце, это VARCHAR, а затем использовать его.
Пункт 4 не имеет значения, потому что пространство для хранения чрезвычайно недорого.
это не просто память, а пропускная способность - процессор, память, резервное копирование, восстановление, передача. Сбережение.
Я бы сказал, что по-прежнему существуют веские причины не использовать nvarchar.
Однако новая разработка должна, вероятно, использовать nvarchar esp. поскольку 64-битные системы становятся нормой. Кроме того, компании (даже небольшие) в настоящее время более широко глобальны.
Вы должны выбрать VARCHAR над NVARCHAR для разных типов столбцов, и выбор будет основан на столбцах.
Типичные столбцы, которые не потребуют дополнительных служебных данных NVARCHAR, будут:
столбцы идентификационного типа: номерные знаки, SSN, идентификаторы диаграммы пациента и т.д.
Кодовые столбцы: Международные коды валют (USD, UKP и т.д.), коды стран ISO (США, Великобритания и т.д.), коды языков (en-us и т.д.), коды сегментов учета и т.д.
Столбцы почтового индекса и почтового индекса.
Я считаю, что сравнение nvarchars является более дорогостоящим, чем varchars, поэтому оно совершенно корректно и даже предпочтительнее в тех местах, где вам действительно не нужны возможности unicode, т.е. для некоторых внутренних идентификаторов.
И стоимость хранения еще имеет значение. Если у вас есть миллиарды строк, то эти "маленькие" различия становятся довольно быстрыми.
Как отмечали другие, это не только стоимость хранения.
Длина столбца будет влиять на количество строк на странице. Имея меньше строк на странице, это означает, что меньшее количество может вписаться в ваши кеши, что снижает производительность. Я предполагаю, что в MSSQL индексированный столбец NVARCHAR будет использовать больше места в индексе. Это означает, что меньше индексов за каждый блок, поэтому больше блоков в индексе, поэтому больше ищет при сканировании (или поиске) индексов, что также замедляет индексированный доступ.
Таким образом, он теряет производительность на каждом фронте. Если вы действительно не заботитесь (или можете измерить производительность и довольны этим, конечно), то это прекрасно. Но если у вас есть подлинное требование хранить символы юникода, конечно, используйте NVARCHAR.
Возможно, что техническая поддержка, полученная при использовании NVARCHAR в вашей базе данных, перевешивает любые затраты на производительность.
Такие вопросы всегда имеют один и тот же ответ: он зависит. Нет волшебного правила, в котором вы должны следовать слепо. Даже использование GOTO в современных языках программирования может быть оправдано: Полезно ли использовать "goto" на языке, который поддерживает циклы и функции? Если да, то почему?
Итак, ответ: используйте свою голову и подумайте о конкретной ситуации. В этом конкретном случае имейте в виду, что вы всегда можете конвертировать из varchar в nvarchar в базу данных, если это изменит ваши требования.
Я видел столбцы nvarchar, преобразованные в varchar по двум причинам:
Приложение использует MSSQL Express Edition, размер базы данных 4 ГБ предел. Переход на стандарт MSSQL Издание будет слишком дорого, если существует множество развертываний баз данных, как это было бы в однопользовательских webapps или приложения со встроенной СУБД. Более дешевый SQL2008 Web Edition может помочь здесь.
nvarchar (4000) недостаточно, но вы не нужен столбец ntext. Так что вы конвертировать в varchar (8000). Однако, в большинстве случаев вам, вероятно, нужно преобразовать в nvarchar (max).
Ваша точка 3 неверна. Системы, предназначенные только для использования в одной стране, не должны беспокоиться о unicode, а некоторые языки/используемые продукты не поддерживают юникод вообще или только частично. Например, TurboTax предназначен только для США (и даже с канадской версией с французским языком по-прежнему остается только LATIN-1), поэтому они не нужно или нужно беспокоиться о unicode и, вероятно, не поддерживать его (я не знаю, делают они это или нет, но даже если они это делают, это просто пример).
"Сегодня приложения всегда должны быть совместимы с Unicode".
вероятно, более корректно выражается как:
"Сегодня приложения всегда должны быть совместимы с Unicode, если не нужно ничего особенного, чтобы правильно обрабатывать Юникод, а ранее существующая кодовая база или любая другая часть приложения не нуждается в обновлении специально для ее поддержки"
Хранение дешевле, чем когда-либо исторически, но если вы можете хранить в два раза больше данных на данном жестком диске, это привлекательно, не так ли?
Также есть RAM для кэширования и твердотельные диски, которые намного дороже, чем жесткие диски. Полезно использовать более компактные форматы данных, когда у вас есть миллионы строк.
Есть ли способ, которым ваш сервер базы данных может использовать UTF-8 в качестве кодировки? Затем вы получаете преимущества низкого хранения для загрузки в основном ASCII и возможности хранить что-либо в диапазоне Unicode, чтобы было возможно расширение.
Я бы попросил вашего поставщика базы данных поддерживать UTF-8 в качестве кодировки для типа VARCHAR SQL. Я не знаю, как это делают другие серверы БД, но я знаю, что вы можете использовать UTF-8 в полях VARCHAR и TEXT, по крайней мере, в MySQL и PostgreSQL.
Все, что было сказано, единственная причина использования не использования кодированного поля UTF-16 - это если вам нужно взаимодействовать с приложениями, которые будут разбиваться на вход UTF-16. Это было бы большинство устаревших приложений, которые были предназначены для обработки текстовых кодировок ASCII или ISO-8815, что лучше обрабатывать UTF-8.
Я не эксперт по этому вопросу. Но почему вы не могли использовать UTF-8 для получения комбинации небольшого пространства и юникода?
Я видел некоторую базу данных, где индексы (индексы?... разные дебаты) были больше данных. Если вы можете избежать половины требований к хранилищу (varchar) в индексе, то предполагается, что это эквивалентно удвоению плотности попадания на заданную страницу и более эффективному заполнению факторинга, что приводит к более быстрому извлечению/записи/блокировке данных и меньшим требованиям к хранению ( уже упоминалось).
Моя склонность "использует NVARCHAR" по умолчанию... но @CadeRoux имеет хорошую точку: если вы уверены, что данные никогда не будут содержать ничего, кроме ASCII - например, номерной знак США - VARCHAR может сэкономить вам крошечная стоимость.
Я бы сказал, что обратная сторона его хорошо сформулированного заявления "DO использовать NVARCHAR" для всего, что будет иметь имена (люди, улицы, места) или текст на естественном языке (электронная почта, чат, статьи, публикации в блогах, фото подписи). В противном случае ваш столбец "firstname" не сможет правильно закодировать "François" или "José", и ваши текстовые столбцы не позволят текст с "чужими" диакритическими знаками или, если на то пошло, очень распространенными американскими символами, такими как знак "¢", знак абзаца "¶", пуля "•". (Потому что ни один из них не является символами ASCII, и нет хорошего стандартного способа поместить их в поле VARCHAR. Поверьте мне: вы повредите себе.)
В ЛЮБОМ проекте, над которым я работал, я НИКОГДА не ругался за использование NVARCHAR, потому что я "растратил слишком много денег компании на дисковое пространство". И если мне пришлось переработать код или схему БД (особенно на живой, производственной системе), затраты, затраченные на повторную установку, ЛЕГКО перевешивали бы "экономию" от покупки диска, который был бы на 50% меньше.
Чтобы действительно понять этот вопрос, вам действительно нужно понять типичные кодировки ASCII, Unicode и Unicode (например, UCS-2 и UTF-8).