Должен ли я когда-либо вызывать RTRIM () для значения varchar или nvarchar?

Question

Я считаю, что ответом на этот вопрос является «нет», но меня интересует мнение сообщества.Значение varchar или nvarchar должно автоматически обрезать конечные пробелы, поэтому я не думаю, что мне когда-либо придется вызывать RTRIM () для такого значения.У какого-нибудь эксперта есть причина, по которой мне это нужно?

(Если теги не дают ясного объяснения, я имею в виду именно Microsoft SQL Server.)

Answer 1

Если ANSI_PADDING включено, то конечные пробелы будут сохраняться даже с типами данных varchar / nvarchar, так что да.

Answer 2

Теоретически, да, из-за SET ANSI_PADDING, который включен по умолчанию и всегда будет включен в будущем.

Если честно, я склонен к RTRIM при записи, чтобы избежать чтения, которое происходит далеко чаще. Это должно произойти только один раз, чтобы испортить вам день ...

Answer 3

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

Запустите этот тест, чтобы понять, что я имею в виду:

create table #temp (test varchar (10))

insert #temp
values ('test   ')
insert #temp
values ('test2 ')
insert #temp
values ('test    ')
insert #temp
values ('test')

select test + '1' from #temp
select rtrim(test) +'1' from #temp
select * from #temp where test = 'test'

Answer 4

SQL Server (и большинство других СУБД SQL) действительно отстой, когда дело доходит до таких вещей:

insert into Blah values ('careful ');
insert into Blah values ('careful');

Предположим, что есть столбец идентификатора или что-то еще

Значения будут сравниваться, чтобы быть одинаковыми, по сообщениям будут иметь одинаковую длину, но на самом деле не будут иметь те же данные. Конкатенация

select Bar + 'something' from Blah

и у одного будет пробел, у другого - нет.

Answer 5

Это зависит, например, от набора данных клиента Delphi и файла midas.dll, используемых с ним (по крайней мере версии 7 и более ранних (не знаю сейчас)), которые имели ошибку, если длина данных в поле Nvarcharменьше указанного, они использовали для дополнения.

На стороне базы данных не было такой большой проблемы, но на клиентах это доставляло нам немало проблем.

Answer 6

Странный случай с оператором LIKE.Например:

select 1 where convert(nvarchar(10), 'a') like convert(nvarchar(10), '%a ')

не вернет результат.

Answer 7

(n)varchar использует только объем используемого пространства, поэтому он не должен включать пробелы.Обычно он используется при удалении лишнего пробела из поля char, которое перераспределено, то есть char(30) только с 10 символами.