VARCHAR похож на 90-е?

Я не эксперт в этом вопросе. Но по какой причине вы не могли использовать UTF-8, чтобы получить комбинацию небольшого пространства и юникода?

Я бы сказал, что все еще есть веские причины не использовать nvarchar.

• Место для хранения ограничено, например, на общем хосте или в базе данных. В самом деле огромный.
• Производительность имеет решающее значение.
• Разработка Brownfield (т.е. в базе данных есть таблицы, использующие varchar).
• Вы интегрируетесь с другой старой системой, которая понимает только однобайтовые символы и / или varchar.

Однако в новой разработке, вероятно, следует использовать nvarchar esp. поскольку 64-битные системы становятся нормой. Кроме того, компании (даже небольшие) теперь более глобальны.

Хранение дешевле, чем когда-либо раньше, но все же, если вы можете хранить вдвое больше данных на одном жестком диске, это привлекательно, не правда ли?

Также есть оперативная память для кэширования и твердотельные накопители, которые намного дороже жестких дисков. Когда у вас миллионы строк, полезно использовать более компактные форматы данных.

Ваш пункт 3 недействителен. Системы, которые предназначены только для использования в одной стране, не должны беспокоиться о юникоде, а некоторые используемые языки / продукты не поддерживают юникод полностью или частично. Например, TurboTax предназначен только для США (и даже с канадской версией с французским остается только LATIN-1), поэтому им не нужно беспокоиться о Unicode и, вероятно, не поддерживать его (я не знаю, есть они или нет, но даже если они это сделают, это всего лишь пример).

«Современные приложения всегда должны быть совместимы с Unicode».

вероятно, более корректно выражается как:

«Современные приложения всегда должны быть совместимы с Unicode, если ничего особенного не требуется для правильной обработки Unicode, а ранее существующая кодовая база или любая другая часть приложения не нуждается в обновлении специально для ее поддержки»

Point 4 doesn't matter because storage space is extremely inexpensive.

это не просто хранилище, а пропускная способность - процессор, память, резервное копирование, восстановление, передача. Сохранить.

Вы сопоставляете тип данных с данными, которые будут храниться в столбце. С помощью аналогичного аргумента вы могли бы сказать, почему бы не хранить все данные в столбцах NVARCHAR, потому что числа и даты могут быть представлены как строки цифр.

Если наилучшим соответствием данных, которые будут храниться в столбце, является VARCHAR, используйте его.

Есть ли способ для вашего сервера базы данных использовать UTF-8 в качестве кодировки? Затем вы получаете преимущества небольшого объема памяти для загрузки в основном ASCII и возможность хранить что-либо в диапазоне Unicode, так что расширение возможно.

Я бы попросил вашего поставщика базы данных поддержать UTF-8 в качестве кодировки для типа SQL VARCHAR. Я не знаю, как это делают другие серверы БД, но я знаю, что вы можете использовать UTF-8 в полях VARCHAR и TEXT, по крайней мере, в MySQL и PostgreSQL.

Все, что было сказано, единственная причина, по которой нет использует поле в кодировке UTF-16, - это если вам нужно взаимодействовать с приложениями, которые не работают при вводе UTF-16. Это будет большинство устаревших приложений, которые были разработаны для обработки текстовых кодировок ASCII или ISO-8815, которые лучше обрабатывали бы UTF-8.

Как отмечали другие, дело не только в стоимости хранения.

Длина столбца влияет на количество строк на странице. Меньшее количество строк на странице означает, что меньшее количество может поместиться в ваши кеши, что снижает производительность. Я предполагаю, что в MSSQL индексируемый столбец NVARCHAR будет занимать больше места в индексе. Это означает меньшее количество записей индекса на блок, следовательно, больше блоков в индексе, следовательно, больше запросов при сканировании (или поиске) индексов, что также замедляет индексированный доступ.

Таким образом, вы теряете производительность по всем направлениям. Если вам действительно все равно (или вы можете измерить производительность и, конечно, довольны), то это нормально. Но если у вас есть настоящая потребность в хранении символов Юникода, конечно, используйте NVARCHAR.

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

Я считаю, что сравнение nvarchars дороже, чем varchars, поэтому оно вполне допустимо и даже предпочтительнее в тех местах, где вам действительно не нужны возможности Unicode, то есть для некоторых внутренних идентификаторов.

А стоимость памяти еще имеет значение. Если у вас есть миллиарды строк, эти «маленькие» различия довольно быстро становятся большими.

На такие вопросы всегда есть один и тот же ответ: По-разному. Не существует магического правила, которому следует слепо следовать. Даже использование GOTO в современных языках программирования может быть оправдано: Выгодно ли когда-нибудь использовать goto на языке, поддерживающем циклы и функции? Если да, то почему?

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

Я видел столбцы nvarchar, преобразованные в varchar, по двум причинам:

1. Приложение использует MSSQL выражать Версия с размером базы данных 4 ГБ предел. Переход на стандарт MSSQL Издание было бы слишком дорого, если бы есть много развертываний баз данных, как в однопользовательских веб-приложениях или приложения со встроенной СУБД. Более дешевая версия SQL2008 Web Edition мог бы здесь помочь.

2. nvarchar (4000) недостаточно но ты не нужен столбец ntext. Так что вы преобразовать в varchar (8000). Тем не мение, в большинстве случаев вам, вероятно, следует преобразовать в nvarchar (max).

Вы должны выбрать VARCHAR вместо NVARCHAR для многих различных типов столбцов, и выбор будет для каждого столбца.

Типичные столбцы, которые не потребуют дополнительных накладных расходов, связанных с NVARCHAR, будут:

Столбцы ID-типа: номерные знаки, SSN, идентификаторы карты пациента и т. д.

Столбцы кодов: коды международных валют (USD, UKP и т. д.), Коды стран ISO (США, Великобритания и т. д.), Коды языков (en-us и т. д.), Коды сегментов учета и т. д.

Почтовый индекс и столбцы почтового индекса.

Я видел базу данных, в которой индексы (индексы? ... разные дискуссии) были больше данных. Если можно обойтись с половиной требований к хранилищу (varchar) в индексе, то предполагается, что это равняется удвоенной плотности совпадений данной страницы и более эффективному факторингу заполнения, ведущему к более быстрому извлечению / записи / блокировке данных и меньшим требованиям к хранилищу ( уже упоминалось).

Я склоняюсь к тому, чтобы "использовать NVARCHAR" по умолчанию ... но @CadeRoux имеет хороший аргумент: если вы УВЕРЕНЫ, что данные никогда не будут содержать ничего, кроме ASCII - например, номерной знак США - VARCHAR может сэкономить вам немного Стоимость.

Я бы сказал, что оборотной стороной его удачно поставленного заявления является «ИСПОЛЬЗУЙТЕ NVARCHAR» для всего, что будет иметь имена (люди, улицы, места) или текст на естественном языке (электронная почта, чат, статьи, сообщения в блогах, подписи к фотографиям). В противном случае столбец «имя» не сможет правильно кодировать «Франсуа» или «Хосе», а в текстовых столбцах не будет текста с «иностранными» диакритическими знаками или, если на то пошло, очень распространенными американскими символами, такими как центрирующий знак «¢», знак абзаца «¶», маркер «•». (Потому что ни один из них не является Символы ASCII, и нет хорошего стандартного способа поместить их в поле VARCHAR. Поверьте мне: вы навредите себе.)

В ЛЮБОМ проекте, над которым я работал, меня НИКОГДА не ругали за использование NVARCHAR, потому что я «тратил слишком много денег компании на дисковое пространство». И если бы мне пришлось переделывать код или схему БД (особенно в действующей производственной системе), затраты, потраченные на повторную установку, ЛЕГКО перевесили бы «экономию» от покупки диска, который был на 50% меньше.

Чтобы действительно понять этот вопрос, вам действительно нужно понимать типичные кодировки ASCII, Unicode и Unicode (например, UCS-2 и UTF-8).