Почему все еще существует тип данных varchar?

Многие из моих баз данных имеют поля, определенные как varchars. Это не было большой проблемой, так как я живу и работаю в Америке (где единственный язык, который существует - это «американский». Хм )

После работы с базами данных в течение примерно 5 лет я обнаружил, что в конечном итоге у меня возникли проблемы с ограниченным характером поля varchar, и я должен изменить свои поля для хранения данных в виде nvarchars. После того, как мне пришлось сделать еще одно обновление таблицы, преобразовав поле varchar в nvarchar, у меня возникла мысль - почему мы до сих пор делаем это так? Я давно принял решение определить все новые текстовые поля для nvarchar вместо varchar, что я научился делать из своих учебников, когда учился в школе 10 лет назад.

Это 2011 год, и в прошлом году вышла новая версия SQL Server. Почему мы продолжаем поддерживать тип данных varchar, когда вместо этого можем / должны использовать nvarchar?

Я знаю, что часто утверждают, что nvarchars "вдвое больше", чем varchars, поэтому использование пространства хранения может быть одним из аргументов в пользу mactaining varcars.

Однако современные пользователи могут определить свои nvarchars для хранения данных как UTF-8 вместо UTF-16 по умолчанию, если они хотят сэкономить на пространстве хранения. Это позволит использовать 8-битное кодирование, если это в первую очередь желательно, и при этом дает гарантию, что редкий 2-8-байтовый символ, вставленный в их БД, ничего не сломает.

Я что-то пропустил? Есть ли веская причина, почему это не изменилось за последние 15-20 лет?

1. Работа с varchar достаточно хороша для многих западноевропейских языков (норвежского, датского, немецкого, французского, голландского и т. д.), с некоторыми проблемами сопоставления

2. Посмотрите на производительность SO varchar vs nvarchar nvarchar имеет серьезные последствия для производительности

3. Это тривиально по сравнению с датами MDY против DMY

В дополнение к ответам, касающимся стандартов и совместимости, следует также учитывать производительность. Хотя дисковое пространство легко принять за дешевизну, администраторы баз данных / разработчики часто игнорируют тот факт, что производительность запросов иногда напрямую связана с размером строки / страницы таблицы. Использование NVARCHARвместо VARCHAR(когда это не нужно) будет эффективно удваивать размер строки для ваших полей символов. Если у вас есть, скажем, 5 или 10 полей длиной 50, вы говорите о потенциальном добавлении дополнительных 500 байтов в строку. Если у вас широкая таблица, это может раздвинуть каждую строку на нескольких страницах и негативно повлиять на производительность.

У многих организаций все еще имеется большая установленная база приложений, интерфейсов, платформ и инструментов, которые принимают однобайтовые символы. Базы данных редко живут в изоляции - они являются частью ИТ-экосистемы. Если у вас есть тысячи компонентов и миллионы строк кода, зависящих от однобайтовых символов, вам понадобится веская причина, чтобы инвестировать время и деньги, необходимые для перехода на Unicode. Изменения в таком масштабе могут занять годы. В некоторых местах Юникод все еще относительно новый, редкий или не полностью поддерживаемый.

VARCHAR и NVARCHAR являются частью стандарта ISO ISO. Удаление или отказ от поддержки VARCHAR в SQL Server станет шагом назад в отношении совместимости и переносимости.

В качестве альтернативы современные пользователи могут определить свои nvarchars для хранения данных как UTF-8 вместо UTF-16 по умолчанию, если они хотят сэкономить на пространстве хранения.

Это именно то, что делает большинство баз данных с открытым исходным кодом VARCHAR.

• MySQL обеспечивает utf8иucs2 «сопоставления».
• SQLite предоставляет вам выбор между UTF-8 (по умолчанию) и UTF-16.
• PostgreSQL поддерживает UTF-8 (но не UTF-16).

Нет необходимости иметь два отдельных типа строк.

Microsoft является странной из-за того, что 8-битные строки предназначены для устаревших кодировок, а Unicode = UTF-16. Что, вероятно, связано с лечением самого Windows API charи wchar_tтак далее.

Потому что некоторые из нас строят более легкие, меньшие по размеру приложения на менее современных аппаратных средствах, которые не нуждаются в возможностях Unicode. Возможно, нам нужно будет изменить это позже, но сейчас нам это просто не нужно. Мне нравится, когда мои струны занимают половину пространства, которое они должны были бы иметь при NVARCHAR.