TSQL, снабжающий префиксом строковый литерал на вставке - какое-либо значение к этому, или избыточный?
Я просто наследовал проект, который имеет код, подобный следующему (довольно простому) примеру:
DECLARE @Demo TABLE
(
Quantity INT,
Symbol NVARCHAR(10)
)
INSERT INTO @Demo (Quantity, Symbol)
SELECT 127, N'IBM'
Мой интерес с N перед строковым литералом.
Я понимаю что префикс N должен указать кодирование (в этом случае, Unicode). Но так как выбор только для вставки в поле, которое ясно уже является Unicode, разве это не оценило бы быть автоматически восходящим?
Я выполнил код без N и это, кажется, работает, но я пропускаю что-то, что предназначил предыдущий программист? Или был N контроль на его части?
Я ожидаю поведение, подобное тому, когда я передам int к a decimal (автовосходящее) поле. Я могу избавиться от тех Ns?
2 ответа
Ваш тест не совсем корректен, попробуйте вместо него что-то вроде китайского иероглифа, я помню, если вы не поставите префикс, он не вставит правильный символ
пример, первый показывает знак вопроса, а нижний - квадрат
select '作'
select N'作'
Лучший пример, даже здесь вывод не такой же
declare @v nvarchar(50), @v2 nvarchar(50)
select @v = '作', @v2 = N'作'
select @v,@v2
Поскольку то, что вы выглядите как таблица акций, почему вы используете юникод, есть ли вообще символы, которые являются юникодом. Я никогда не видел ни одного, и это касается ISIN, CUSIPS и SEDOLS
Да, SQL Server автоматически преобразует (расширяет, понижает) varchar в nvarchar, поэтому в этом случае вы можете удалить N. Конечно, если вы указываете строковый литерал, в котором символы фактически не присутствуют в параметрах сортировки по умолчанию в базе данных, тогда он вам понадобится.
Это похоже на то, что вы можете добавить к числу суффикс «L» в C и др., Чтобы указать, что это длинный литерал вместо int. Написание N'IBM - это либо точность, либо раб привычки, в зависимости от вашей точки зрения.
Одна ловушка для неосторожных: nvarchar не преобразуется автоматически в varchar, и это может быть проблемой, если ваше приложение полностью поддерживает Unicode, а ваша база данных - нет. Например, у нас это было с драйвером jTDS JDBC, который связывает все значения параметров как nvarchar, в результате чего фактически получают такие операторы:
select * from purchase where purchase_reference = N'AB1234'
(где Purchase_reference был столбцом varchar)
Поскольку автоматические преобразования являются только односторонними, это стало:
select * from purchase where CONVERT(NVARCHAR, purchase_reference) = N'AB1234'
, и поэтому индекс Purchase_reference не использовался.
Напротив, все в порядке: если покупка_reference была nvarchar, а приложение передало параметр varchar, то переписанный запрос:
select * from purchase where purchase_reference = CONVERT(NVARCHAR, 'AB1234')
подойдет. В конце концов, нам пришлось отключить параметры привязки как Unicode, что вызвало множество проблем с i18n, которые считались менее серьезными.