Является ли VARCHAR полностью 90-х годов?

Ответ 1

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

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

Ответ 2

Пункт 4 не имеет значения, потому что пространство для хранения чрезвычайно недорого.

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

Ответ 3

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

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

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

Ответ 4

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

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

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

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

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

Ответ 5

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

И стоимость хранения еще имеет значение. Если у вас есть миллиарды строк, то эти "маленькие" различия становятся довольно быстрыми.

Ответ 6

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

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

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

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

Ответ 7

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

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

Ответ 8

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

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

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

Ответ 9

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

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

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

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

Ответ 10

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

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

Ответ 11

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

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

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

Ответ 12

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

Ответ 13

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

Ответ 14

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

Я бы сказал, что обратная сторона его хорошо сформулированного заявления "DO использовать NVARCHAR" для всего, что будет иметь имена (люди, улицы, места) или текст на естественном языке (электронная почта, чат, статьи, публикации в блогах, фото подписи). В противном случае ваш столбец "firstname" не сможет правильно закодировать "François" или "José", и ваши текстовые столбцы не позволят текст с "чужими" диакритическими знаками или, если на то пошло, очень распространенными американскими символами, такими как знак "¢", знак абзаца "¶", пуля "•". (Потому что ни один из них не является символами ASCII, и нет хорошего стандартного способа поместить их в поле VARCHAR. Поверьте мне: вы повредите себе.)

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

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