Чем отличается varchar от nvarchar

nchar и nvarchar (Transact-SQL)

Символьные типы данных имеют фиксированный (nchar) или переменный (nvarchar) размер. Начиная с SQL Server 2012 (11.x) при использовании параметров сортировки с поддержкой дополнительных символов эти типы данных хранят весь диапазон символьных данных Юникод и используют кодировку UTF-16. Если указаны параметры сортировки без поддержки дополнительных символов, эти типы данных хранят только подмножество символьных данных, поддерживаемых кодировкой UCS-2.

Аргументы

nchar [ ( n ) ]

Строковые данные фиксированного размера. n определяет размер строки в парах байтов и должен быть значением от 1 до 4000. Размер хранилища — дважды n байт. В случае с кодировкой UCS-2 размер при хранении определяется как дважды n байт, а количество хранимых символов равно n. Для кодировки UTF-16 размер хранилища по-прежнему составляет два раза n байтов, но количество символов, которые могут быть сохранены, может быть меньше n , так как дополнительные символы используют две пары байтов (также называемые суррогатной парой). Синонимами типа nchar по стандарту ISO являются типы national char и national character.

nvarchar [ ( n | max ) ]

Строковые данные переменного размера. n определяет размер строки в парах байтов и может быть значением от 1 до 4000. Значение max указывает, что максимальный размер при хранении составляет 2^31-1 символов (2 ГБ). Размер при хранении определяется как дважды n байт + 2 байта. В случае с кодировкой UCS-2 размер при хранении определяется как дважды n байт + 2 байта, а количество хранимых символов равно n. Для кодировки UTF-16 размер хранилища по-прежнему составляет 2 байта + 2 байта, но количество символов, которые могут быть сохранены, может быть меньше n, так как дополнительные символы используют две пары байтов (также называемые суррогатной парой). Синонимами типа nvarchar по стандарту ISO являются типы national char varying и national character varying.

Remarks

Распространенное заблуждение заключается в том, что при использовании nchar(n) и nvarchar(n)n определяет количество символов. Однако в nchar(n) и nvarchar(n)n определяет длину строки в парах байтов (0–4000). n никогда не определяет количество хранимых символов. Это аналогично определению char(n) и varchar(n).

Неправильное представление возникает из-за того, что при использовании символов, определенных в диапазоне Юникода от 0 до 65 535, на каждую пару байтов может храниться по одному символу. Однако в более высоких диапазонах Юникода (от 65 536 до 1 114 111) один символ может использовать две пары байтов. Например, в столбце, определенном как nchar(10), компонент Компонент Database Engine может хранить 10 символов, использующих одну пару байтов (диапазон Юникода от 0 до 65 535), но менее 10 символов при использовании двух пар байтов (диапазон Юникода от 65 536 до 1 114 111). Дополнительные сведения о хранении символов Юникода и их диапазонах см. в разделе Различия в хранении UTF-8 и UTF-16.

Если значение n в определении данных или инструкции объявления переменной не указано, длина по умолчанию равна 1. Когда n не указано функцией CAST, длина по умолчанию равна 30.

При использовании nchar или nvarchar рекомендуется:

• использовать nchar, если размеры записей данных в столбцах одинаковые;
• использовать nvarchar, если размеры записей данных в столбцах существенно отличаются;
• использовать nvarchar(max), если размеры записей данных в столбцах существенно отличаются и длина строки может превышать 4000 пар байтов.

sysname — это системный определяемый пользователем тип данных, который функционально эквивалентен nvarchar(128), за исключением того, что он не допускает значения NULL. Тип sysname используется для ссылки на имена объектов баз данных.

Объектам, использующим nchar или nvarchar , назначаются параметры сортировки по умолчанию для базы данных, если только определенные параметры сортировки не назначены с помощью COLLATE предложения .

SET ANSI_PADDING всегда ON для nchar и nvarchar. SET ANSI_PADDING OFF не применяется к типам данных nchar или nvarchar .

Префиксировать символьные строковые константы Юникода буквой N , чтобы сообщить о входных данных UCS-2 или UTF-16 в зависимости от того, используются ли параметры сортировки SC. N Без префикса строка преобразуется в кодовую страницу базы данных по умолчанию, которая может не распознавать определенные символы. Начиная с SQL Server 2019 (15.x), при использовании параметров сортировки с поддержкой UTF-8 кодовая страница по умолчанию может хранить кодировку Юникода UTF-8.

При префиксе строковой константы буквой N неявное преобразование приведет к созданию строки UCS-2 или UTF-16, если преобразуемая константа не превышает максимальную длину для строкового типа данных nvarchar (4000). В противном случае неявное преобразование приведет к большому значению nvarchar(max).

Каждому ненулевому столбцу varchar(max) и nvarchar(max) необходимо дополнительно выделить 24 байта памяти, которые учитываются в максимальном размере строки в 8060 байт во время операции сортировки. Эти дополнительные байты могут неявно ограничивать число ненулевых столбцов varchar(max) или nvarchar(max) в таблице. При создании таблицы или во время вставки данных не возникает особых ошибок (кроме обычного предупреждения о том, что максимальный размер строки превышает максимально допустимое значение в 8060 байт). Такой большой размер строки может приводить к ошибкам (например, ошибке 512), которые пользователи не ожидают во время обычных операций. Примерами операций могут служить обновление ключа кластеризованного индекса или сортировка полного набора столбцов.

Преобразование символьных данных

Сведения о преобразовании символьных данных см. в статье char и varchar (Transact-SQL).

См. также раздел

• ALTER TABLE (Transact-SQL)
• Функции CAST и CONVERT (Transact-SQL)
• COLLATE (Transact-SQL)
• Инструкция CREATE TABLE (Transact-SQL)
• Типы данных (Transact-SQL)
• DECLARE @local_variable (Transact-SQL)
• LIKE (Transact-SQL)
• SET ANSI_PADDING (Transact-SQL)
• SET @local_variable (Transact-SQL)
• Поддержка параметров сортировки и Юникода
• Однобайтовые и многобайтовые кодировки

Типы char и varchar (Transact-SQL)

Символьные типы данных имеют фиксированный (char) или переменный (varchar) размер. Начиная с SQL Server 2019 (15.x) при использовании параметров сортировки с поддержкой UTF-8 эти типы данных хранят весь диапазон символьных данных Юникод и используют кодировку UTF-8. Если указаны параметры сортировки без поддержки UTF-8, эти типы данных хранят только подмножество символьных данных, поддерживаемых соответствующей кодовой страницей указанных параметров сортировки.

Аргументы

char [ ( n ) ]

Строковые данные фиксированного размера. n определяет размер строки в байтах и должно иметь значение от 1 до 8000. Для наборов символов однобайтовой кодировки, таких как Latin , размер хранилища равен n байтам, а количество символов, которые можно хранить, также равно n. Для многобайтовых кодировок размер при хранения тоже равен n байт, но количество хранимых символов может быть меньше n. Синонимом по стандарту ISO для типа char является character. Дополнительные сведения о кодировках см. в статье Однобайтовые и многобайтовые кодировки.

varchar [ ( n | max ) ]

Строковые данные переменного размера. Используйте n для определения размера строки в байтах и может быть значением от 1 до 8 000 или использовать максимальное значение, чтобы указать размер ограничения столбца до максимального объема хранилища 2^31-1 байт (2 ГБ). Для наборов символов кодировки с одним байтом, например Latin , размер хранилища равен n байтам + 2 байтам, а количество символов, которые можно сохранить, также равно n. Для многобайтовых кодировок размер при хранения тоже равен n байт + 2 байта, но количество хранимых символов может быть меньше n. Синонимы ISO для varchar являются разными или символьными. Дополнительные сведения о кодировках см. в статье Однобайтовые и многобайтовые кодировки.

Замечания

Распространенное заблуждение заключается в том, чтобы думать, что с char(n) и varchar(n), n определяет количество символов. Однако в char(n) и varchar(n) n определяет длину строки в байтах (от 0 до 8 000). n никогда не определяет количество хранимых символов. Это аналогично определению nchar(n) и nvarchar(n).

Неправильное представление происходит, так как при использовании однобайтовой кодировки размер хранилища char и varchar составляет n байтов, а число символов также равно n. Однако для многобайтовой кодировки, например UTF-8, более высокие диапазоны Юникода (от 128 до 114 111) приводят к одному символу с использованием двух или более байтов. Например, в столбце, определенном как char(10), ядро СУБД может хранить 10 символов, использующих однобайтовое кодирование (диапазон Юникода от 0 до 127), но менее 10 символов при использовании многобайтовой кодировки (диапазон Юникода от 128 до 114 111). Дополнительные сведения о хранении символов Юникода и их диапазонах см. в разделе Различия в хранении UTF-8 и UTF-16.

Если значение n в определении данных или инструкции объявления переменной не указано, длина по умолчанию равна 1. Если n не указан при использовании CAST и CONVERT функциях, длина по умолчанию составляет 30.

Объекты, использующие char или varchar , назначаются параметры сортировки по умолчанию базы данных, если только не назначено определенное параметры сортировки с помощью COLLATE предложения. Параметры сортировки контролируют кодовую страницу, используемую для хранения символьных данных.

Многобайтовые кодировки в SQL Server включают следующие:

• двухбайтовые кодировки (DBCS) для некоторых языков Восточной Азии, использующих кодовые страницы 936 и 950 (китайский), 932 (японский) или 949 (корейский).
• UTF-8 с кодовой страницей 65001. Область применения: SQL Server 2019 (15.x) и более поздних версий.

Если у вас есть сайты, поддерживающие несколько языков, примите к сведению следующие рекомендации:

• Для поддержки Юникода и минимизации проблем с преобразованием символов рекомендуем использовать параметры сортировки с поддержкой UTF-8 (начиная с SQL Server 2019 (15.x)).
• Если используется предыдущая версия SQL Server ядро СУБД, рекомендуется использовать типы данных Юникод nchar или nvarchar, чтобы свести к минимуму проблемы с преобразованием символов.

Если вы используете char или varchar, рекомендуется:

• Если размеры записей данных столбцов постоянны, используйте char.
• Если размеры записей данных столбцов значительно изменяются, используйте varchar.
• использовать varchar(max), если размеры записей данных в столбцах существенно отличаются и длина строки может превышать 8000 байт.

Если SET ANSI_PADDING выполняется OFF либо CREATE TABLE ALTER TABLE выполняется, столбец char, определенный как NULL, обрабатывается как varchar.

Для каждого столбца varchar(max) или nvarchar(max) требуется 24 байта дополнительного фиксированного выделения, которое подсчитывает ограничение строки 8060 байтов во время операции сортировки. Это может неявно ограничивать число ненулевых столбцов varchar(max) или nvarchar(max), которые могут быть созданы в таблице.

При создании таблицы или во время вставки данных не возникает особых ошибок (кроме обычного предупреждения о том, что максимальный размер строки превышает максимально допустимое значение в 8060 байт). Такой размер строки может вызывать ошибки (например, ошибку 512) во время некоторых обычных операций, таких как обновление ключа кластеризованного индекса, или сортировки полного набора столбцов, которая происходит только во время выполнения операции.

Преобразование символьных данных

При преобразовании символьного выражения в символьный тип данных другой длины значения, слишком длинные для нового типа данных, усекаются. Тип uniqueidentifier считается символьным типом, используемым при преобразовании из символьного выражения, поэтому на него распространяются правила усечения при преобразовании в символьный тип. См. раздел «Примеры».

Если символьное выражение преобразуется в символьное выражение другого типа данных или размера, например из char(5) в varchar(5) или из char(20) в char(15), то преобразованному значению присваиваются параметры сортировки входного значения. Если несимвольное выражение преобразуется в символьный тип данных, то преобразованному значению присваиваются параметры сортировки, заданные по умолчанию в текущей базе данных. В любом случае необходимые параметры сортировки можно присвоить с помощью предложения COLLATE.

Преобразования страниц кода поддерживаются для типов данных char и varchar, но не для текстового типа данных. Как и в ранних версиях SQL Server, о потере данных во время преобразования кодовых страниц не сообщается.

Символьные выражения, которые преобразуются в приближенный тип данных numeric, могут содержать необязательную экспоненциальную нотацию Это нотация является строчным или верхним регистром e E , за которым следует необязательный знак плюс ( + ) или минус ( — ), а затем число.

Символьные выражения, которые преобразуются в точный числовый тип данных, должны состоять из цифр, десятичной запятой и необязательного плюса ( + ) или минуса ( — ). Начальные пробелы не учитываются. Разделители запятой, такие как разделитель 123,456.00 тысяч, не допускаются в строке.

Символьные выражения, преобразованные в типы данных money или smallmoney , также могут включать необязательный десятичный знак и знак доллара ( $ ). Разделители запятой, как и в $123,456.00 , разрешены.

Когда пустая строка преобразуется в int, его значение становится 0 . Когда пустая строка преобразовывается в дату, ее значением становится значение даты по умолчанию, то есть 1900-01-01 .

Примеры

А. Отображение значения по умолчанию n при использовании в объявлении переменной

В следующем примере показано значение по умолчанию n равно 1 для типов данных char и varchar , когда они используются в объявлении переменной.

DECLARE @myVariable AS VARCHAR = 'abc'; DECLARE @myNextVariable AS CHAR = 'abc'; --The following returns 1 SELECT DATALENGTH(@myVariable), DATALENGTH(@myNextVariable); GO 

B. Отображение значения по умолчанию n при использовании varchar с CAST и CONVERT

В следующем примере показано, что значение по умолчанию n равно 30, если типы данных char или varchar используются с CAST и CONVERT функциями.

DECLARE @myVariable AS VARCHAR(40); SET @myVariable = 'This string is longer than thirty characters'; SELECT CAST(@myVariable AS VARCHAR); SELECT DATALENGTH(CAST(@myVariable AS VARCHAR)) AS 'VarcharDefaultLength'; SELECT CONVERT(CHAR, @myVariable); SELECT DATALENGTH(CONVERT(CHAR, @myVariable)) AS 'VarcharDefaultLength'; 

C. Преобразование данных для отображения

В следующем примере два столбца преобразуются в символьные типы, после чего к ним применяется стиль, применяющий к отображаемым данным конкретный формат. Тип денег преобразуется в символьные данные и стиль 1 , который отображает значения с запятыми каждые три цифры слева от десятичной точки и две цифры справа от десятичной запятой. Тип даты и времени преобразуется в символьные данные и стиль 3 , который отображает данные в формате dd/mm/yy . WHERE В предложении тип денег привязывается к типу символов для выполнения операции сравнения строк.

USE AdventureWorks2022; GO SELECT BusinessEntityID, SalesYTD, CONVERT (VARCHAR(12),SalesYTD,1) AS MoneyDisplayStyle1, GETDATE() AS CurrentDate, CONVERT(VARCHAR(12), GETDATE(), 3) AS DateDisplayStyle3 FROM Sales.SalesPerson WHERE CAST(SalesYTD AS VARCHAR(20) ) LIKE '1%'; 

BusinessEntityID SalesYTD DisplayFormat CurrentDate DisplayDateFormat ---------------- --------------------- ------------- ----------------------- ----------------- 278 1453719.4653 1,453,719.47 2011-05-07 14:29:01.193 07/05/11 280 1352577.1325 1,352,577.13 2011-05-07 14:29:01.193 07/05/11 283 1573012.9383 1,573,012.94 2011-05-07 14:29:01.193 07/05/11 284 1576562.1966 1,576,562.20 2011-05-07 14:29:01.193 07/05/11 285 172524.4512 172,524.45 2011-05-07 14:29:01.193 07/05/11 286 1421810.9242 1,421,810.92 2011-05-07 14:29:01.193 07/05/11 288 1827066.7118 1,827,066.71 2011-05-07 14:29:01.193 07/05/11 

D. Преобразование данных uniqueidentifer

В следующем примере значение uniqueidentifier преобразуется в тип данных char.

DECLARE @myid uniqueidentifier = NEWID(); SELECT CONVERT(CHAR(255), @myid) AS 'char'; 

Следующий пример показывает усечение данных, когда значение является слишком длинным для преобразования в заданный тип данных. Так как тип данных uniqueidentifier ограничен 36 символами, все символы, выходящие за пределы этой длины, будут усечены.

DECLARE @ID NVARCHAR(max) = N'0E984725-C51C-4BF4-9960-E1C80E27ABA0wrong'; SELECT @ID, CONVERT(uniqueidentifier, @ID) AS TruncatedValue; 

String TruncatedValue -------------------------------------------- ------------------------------------ 0E984725-C51C-4BF4-9960-E1C80E27ABA0wrong 0E984725-C51C-4BF4-9960-E1C80E27ABA0 (1 row(s) affected) 

См. также

• nchar и nvarchar (Transact-SQL)
• CAST и CONVERT (Transact-SQL)
• COLLATE (Transact-SQL)
• Преобразование типов данных (ядро СУБД)
• Типы данных (Transact-SQL)
• Оценка размера базы данных
• Поддержка параметров сортировки и Юникода
• Однобайтовые и многобайтовые кодировки

Разница между Варчаром и Нварчаром

Основное различие: на сервере SQL оба ссылаются на типы данных. Varchar обозначает строку символов переменной длины. Varchar хранит данные ASCII, тогда как Nvarchar хранит данные UNICODE.

Типы данных играют важную роль в описании формы данных. Это полезно для хранения данных. Два таких типа данных — это varchar и nvarchar. Varchar обозначает строку символов переменной длины. Varchar в основном занимает количество байтов, равное количеству символов, которые хранятся в столбце. Varchar используется, когда не-Unicode символы должны быть сохранены. Он распределяет память в зависимости от количества вставленных символов. Например, varchar (30) будет первоначально выделять память нулевых символов в течение времени объявления. Однако предположим, что вставлено только 20 символов, тогда в этом случае память будет выделена только для этих 20 символов.

Нварчар тих, как и Варчар. Однако он используется для хранения символов Unicode, и, таким образом, можно хранить несколько языков в базе данных. Nvarchar предпочтительнее varchar, так как он не требует преобразования кодировки для чтения или записи в базу данных каждый раз. С другой стороны, преобразования требуют времени и подвержены ошибкам. Однако использовать nvarchar следует только в том случае, если необходимо хранить данные на разных языках, то есть для сопоставления, для которого требуется два байта для хранения одного символа.

Сравнение между Varchar и Nvarchar в Sql Server:

VARCHAR (п)

NVARCHAR (п)

Varchar хранит данные ASCII

Nvarchar хранит данные UNICODE.

Количество байтов для каждого символа

Необязательный параметр n range

Значение необязательного параметра n может быть от 1 до 8000. Может хранить до 8000 не-Unicode символов.

Значение необязательного параметра n может быть от 1 до 4000. Может хранить до 4000 символов Unicode / Non-Unicode

Максимум 8000 не-Unicode символов

Максимум 4000 символов Unicode / Non-Unicode.

Различные типы кодовых страниц

Юникод универсальная кодовая страница

Пятьдесят процентов памяти экономится больше, чем по сравнению с nvarchar

Меньше памяти сохранено сравнительно.

Чем отличается varchar от nvarchar

Какие осообенности есть по использованию nvarchar (SQL в связке с .NET приложением). Какие плюсы, какие минусы объясните пожалуйста.

Re: Что лучше использовать nvarchar или varchar

От:	Merle	http://rsdn.ru
Дата:	20.09.05 12:28
Оценка:	4 (1)

Здравствуйте, MrOrbit, Вы писали:

MO>Какие осообенности есть по использованию nvarchar (SQL в связке с .NET приложением). Какие плюсы, какие минусы объясните пожалуйста.
nvarchar, потому как юникод.

Мы уже победили, просто это еще не так заметно.
Re: Что лучше использовать nvarchar или varchar

От:	pkarklin
Дата:	20.09.05 12:28
Оценка:	4 (1)

Здравствуйте, MrOrbit, Вы писали:

MO>Какие осообенности есть по использованию nvarchar (SQL в связке с .NET приложением). Какие плюсы, какие минусы объясните пожалуйста.

Тут надо подходить по критерию необходимости. Типы данных Unicode следует использовать только при необходимости хранения символьных данных более чем на 2х языках одновременно.

Re: Что лучше использовать nvarchar или varchar

От:	Ромашка
Дата:	20.09.05 12:31
Оценка:

Здравствуйте MrOrbit, Вы писали :
> Какие осообенности есть по использованию nvarchar (SQL в связке с .NET
> приложением). Какие плюсы, какие минусы объясните пожалуйста.

Плюсы/минусы Unicode объяснять.

Posted via RSDN NNTP Server 2.0 beta

Всё, что нас не убивает, ещё горько об этом пожалеет.

Re[2]: Что лучше использовать nvarchar или varchar

От:	MrOrbit
Дата:	20.09.05 12:35
Оценка:

Здравствуйте, Ромашка, Вы писали:

Р>Здравствуйте MrOrbit, Вы писали :
>> Какие осообенности есть по использованию nvarchar (SQL в связке с .NET
>> приложением). Какие плюсы, какие минусы объясните пожалуйста.

Р>Плюсы/минусы Unicode объяснять.

Что такое Unicode я прекрасно знаю

У меня вопрос скорее с точки зрения базы данных (SQL Server + .NET) интуитивно я чувствую
что конечно, же лучше использовать Unicode (nvarchar) но прежде я должен убедиться, что в будущем
у меня не возникнет неожиданных проблем (медленное индексирование, ошибки конвертирования при получении данных и т.п)

Re[3]: Что лучше использовать nvarchar или varchar

От:	pkarklin
Дата:	20.09.05 12:42
Оценка:

Здравствуйте, MrOrbit, Вы писали:

MO>интуитивно я чувствую, что конечно, же лучше использовать Unicode (nvarchar)

Вот так вот прям «интуитивно»?!

Re[3]: Что лучше использовать nvarchar или varchar

От:	Ромашка
Дата:	20.09.05 12:46
Оценка:	8 (1)

Здравствуйте MrOrbit, Вы писали :
> У меня вопрос скорее с точки зрения базы данных (SQL Server + .NET)
> интуитивно я чувствую
> что конечно, же лучше использовать Unicode (nvarchar) но прежде я должен
> убедиться, что в будущем

Все зависит от задачи.

> у меня не возникнет неожиданных проблем (медленное индексирование,
> ошибки конвертирования при получении данных и т.п)

Posted via RSDN NNTP Server 2.0 beta

Всё, что нас не убивает, ещё горько об этом пожалеет.

Re[2]: Что лучше использовать nvarchar или varchar

От:	Merle	http://rsdn.ru
Дата:	20.09.05 13:06
Оценка:	+1

Здравствуйте, pkarklin, Вы писали:

P> Типы данных Unicode следует использовать только при необходимости хранения символьных данных более чем на 2х языках одновременно.
Скорее наоборот. Типы данных не unicode можно использовать только если есть 100% гарантия, что не придется использовать больше одного языка одновременно.
Соломка она такая, ее лучше заранее стелить.

Мы уже победили, просто это еще не так заметно.
Re[3]: Что лучше использовать nvarchar или varchar

От:	pkarklin
Дата:	20.09.05 13:14
Оценка:

Здравствуйте, Merle, Вы писали:

M>Скорее наоборот. Типы данных не unicode можно использовать только если есть 100% гарантия, что не придется использовать больше одного языка одновременно.

Эээ. Зачем мне unicode (который будет занимать в 2 раза больше места), если есть 100% гарантия, что в системе будет только английский и русский?!

Re[4]: Что лучше использовать nvarchar или varchar

От:	Merle	http://rsdn.ru
Дата:	20.09.05 13:27
Оценка:

Здравствуйте, pkarklin, Вы писали:

P>Эээ. Зачем мне unicode (который будет занимать в 2 раза больше места), если есть 100% гарантия, что в системе будет только английский и русский?!
Затем, что вероятность проблем от в два раза больше места, меньше вероятности проблем от того, что вдруг вылезет необходимость поддерживать какой-нибудь язык с умляутами.

Мы уже победили, просто это еще не так заметно.
Re[5]: Что лучше использовать nvarchar или varchar

От:	pkarklin
Дата:	20.09.05 13:31
Оценка:

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, pkarklin, Вы писали:

P>>Эээ. Зачем мне unicode (который будет занимать в 2 раза больше места), если есть 100% гарантия, что в системе будет только английский и русский?!
M>Затем, что вероятность проблем от в два раза больше места, меньше вероятности проблем от того, что вдруг вылезет необходимость поддерживать какой-нибудь язык с умляутами.

В моем понимании «100% гарантия, что в системе будет только английский и русский» = 0% «вероятности того, что вдруг вылезет необходимость поддерживать какой-нибудь язык с умляутами». Если 100% уверенности нет, то, естесвенно, надо использовать unicode.

Re[6]: Что лучше использовать nvarchar или varchar

От:	Merle	http://rsdn.ru
Дата:	20.09.05 14:43
Оценка:

Здравствуйте, pkarklin, Вы писали:

P>В моем понимании «100% гарантия, что в системе будет только английский и русский» = 0% «вероятности того, что вдруг вылезет необходимость поддерживать какой-нибудь язык с умляутами». Если 100% уверенности нет, то, естесвенно, надо использовать unicode.
Это просто моя паранойя по поводу того, что 100% гарантии не бывает никогда.

Мы уже победили, просто это еще не так заметно.
Re[7]: Что лучше использовать nvarchar или varchar

От:	Igor Trofimov
Дата:	20.09.05 16:54
Оценка:

Потенциально еще nvarchar может в каком-то месте повести себя менее ожидаемо, чем обычный varchar.
В Ораклятине, например, есть некоторые ограничения в unicode-типах по сравнению с «обычными». Ограничения на размер строки могут оказаться критичнее. Ну и наконец, скорость обработки и объем данных тоже может быть существенен.

Но в общем, если ничего толком пока не знаешь — наверное и правда лучше nvarchar сделать.

Re: Что лучше использовать nvarchar или varchar

От:	_d_m_
Дата:	21.09.05 08:14
Оценка:	4 (1)

Здравствуйте, MrOrbit, Вы писали:

MO>Какие осообенности есть по использованию nvarchar (SQL в связке с .NET приложением). Какие плюсы, какие минусы объясните пожалуйста.

Нативные системные ф-ции Win32 API они все Unicode еще с NT 4, и фрамворк строки тоже Unicode. Вернее в Win32 по две версии ф-ций, например:

int lstrcmp( LPCTSTR lpString1, LPCTSTR lpString2 );

На самом деле это есть ни что иное как макрос, а ф-ций две:

// Unicode int lstrcmpW( wchar_t* lpString1, wchar_t* lpString2 ); // ANSI int lstrcmpA( char* lpString1, char* lpString2 );

Но, lstrcmpA — всего лишь «stub» — заглушка, где выполняется преобразование аргументов строк однобайтовых символов в строки Unicode символов, а затем следует вызов родной ф-ции API lstrcmpW. Про фрамворк уже сказал тоже.

Значит при использовании ANSI строк выполняется их преобразование в Unicode. А если результатом является строка ANSI, то опять преобразование из Unicode. А это снижение производительности работы приложения. Есть ли необходимость снижать быстродействие ценой экономии дешевого дискового пространства? Microsoft говорит вам — нет. А я так же считаю.

Re[2]: Что лучше использовать nvarchar или varchar

От:	pkarklin
Дата:	21.09.05 10:25
Оценка:

Здравствуйте, _d_m_, Вы писали:

___>Значит при использовании ANSI строк выполняется их преобразование в Unicode. А если результатом является строка ANSI, то опять преобразование из Unicode. А это снижение производительности работы приложения. Есть ли необходимость снижать быстродействие ценой экономии дешевого дискового пространства? Microsoft говорит вам — нет. А я так же считаю.

Какие пафосные замечания. Вроде все гладко, преобразование туда\сюда. Но, скажите мне, разве быстродействие клиентского приложения является узким местом в архитектуре клиент\сервер? Правильно. Сервер СУБД, где лопатиться куча данных. И при прочих равных условиях для кэширования одного и того же объема данных в кэше при использовании unicode понадобиться больше памяти, впрочем как и операций ввода\вывода. Вот где действительн будет снижение производительности.

Re[3]: Что лучше использовать nvarchar или varchar

От:	_d_m_
Дата:	21.09.05 11:02
Оценка:

Здравствуйте, pkarklin, Вы писали:

P>Здравствуйте, _d_m_, Вы писали:

___>>Значит при использовании ANSI строк выполняется их преобразование в Unicode. А если результатом является строка ANSI, то опять преобразование из Unicode. А это снижение производительности работы приложения. Есть ли необходимость снижать быстродействие ценой экономии дешевого дискового пространства? Microsoft говорит вам — нет. А я так же считаю.

P>Какие пафосные замечания. Вроде все гладко, преобразование туда\сюда. Но, скажите мне, разве быстродействие клиентского приложения является узким местом в архитектуре клиент\сервер? Правильно. Сервер СУБД, где лопатиться куча данных. И при прочих равных условиях для кэширования одного и того же объема данных в кэше при использовании unicode понадобиться больше памяти, впрочем как и операций ввода\вывода. Вот где действительн будет снижение производительности.

Справедливое замечание. Но тип sysname тем не менее nvarchar(128), да и ядро ОС и .NET — родной формат Unicode. Да и что делать, если у меня клиентское приложение среднее звено, например ASP.NET? Вопрос: сколько памяти и процессорного времени жрет такое преобразование — да тоже не мало.

Re: Что лучше использовать nvarchar или varchar

От:	chabster	chabster.blogspot.com
Дата:	21.09.05 15:41
Оценка:

> Какие осообенности есть по использованию nvarchar (SQL в связке с .NET приложением). Какие плюсы, какие минусы объясните пожалуйста.

МС Сиквел внутренне использует ***ИСКЛЮЧИТЕЛЬНО*** юникод для представления символов. А функции, работающие с varchar/char перекодируют все в юникод и потом на выходе обратно.

Posted via RSDN NNTP Server 1.9
Re[4]: Что лучше использовать nvarchar или varchar

От:	chabster	chabster.blogspot.com
Дата:	21.09.05 15:43
Оценка:

> Справедливое замечание. Но тип sysname тем не менее nvarchar(128), да и ядро ОС и .NET — родной формат Unicode. Да и что делать, если у меня клиентское приложение среднее звено, например ASP.NET? Вопрос: сколько памяти и процессорного времени жрет такое преобразование — да тоже не мало.

Автор: chabster
Дата: 21.09.05
Posted via RSDN NNTP Server 1.9
Re[2]: Что лучше использовать nvarchar или varchar

От:	seregaa	http://blogtani.ru
Дата:	21.09.05 16:03
Оценка:

Здравствуйте, chabster, Вы писали:

C>МС Сиквел внутренне использует ***ИСКЛЮЧИТЕЛЬНО*** юникод для представления символов. А функции, работающие с varchar/char перекодируют все в юникод и потом на выходе обратно.

Неужели они пошли на такое? А можно ссылочку на источник?

Мобильная версия сайта RSDN — http://rsdn.org/forum/rsdn/6938747
Автор: sergeya
Дата: 19.10.17
Re[5]: Что лучше использовать nvarchar или varchar

От:	_d_m_
Дата:	22.09.05 01:55
Оценка:

Здравствуйте, chabster, Вы писали:

>> Справедливое замечание. Но тип sysname тем не менее nvarchar(128), да и ядро ОС и .NET — родной формат Unicode. Да и что делать, если у меня клиентское приложение среднее звено, например ASP.NET? Вопрос: сколько памяти и процессорного времени жрет такое преобразование — да тоже не мало.

C>http://rsdn.ru/forum/?mid=1395135

Автор: chabster
Дата: 21.09.05

И что из этого следует, по твоему мнению?