Dovrei mai aver bisogno di chiamare RTRIM() su un valore varchar o nvarchar?

Question

Credo che la risposta a questa domanda sia "no", ma mi interessa l'opinione della comunità. Un valore varchar o nvarchar dovrebbe ritagliare automaticamente gli spazi bianchi finali, quindi non credo che dovrei mai chiamare RTRIM() su tale valore. Qualche esperto ha una ragione per cui avrei bisogno?

(Nel caso in cui le etichette non rendono chiaro, mi riferisco in particolare a Microsoft SQL Server.)

Answer 1

Se ANSI_PADDING è ON quindi finali saranno conservati, anche con tipi di dati varchar/nvarchar, quindi sì.

Answer 2

Potrebbe non essere necessario per RTRIM per ottenere i valori in una semplice selezione, ma se si vuole per concatenare i valori (ad esempio combinando nome e cognome per mostrare il nome completo) che potrebbe essere necessario.

Esegui questo test per vedere quello che voglio dire:

spazi

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 3

Il (n)varchar utilizza solo la quantità di spazio utilizzato, quindi non dovrebbe includere lo spazio bianco. Viene in genere utilizzato quando si rimuove lo spazio extra da un campo char sovrascritto, vale a dire uno char(30) con solo 10 caratteri.

Answer 4

C'è un caso strano con l'operatore LIKE. Ad esempio:

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

non restituisce un risultato.

Answer 5

In teoria, sì, a causa di SET ANSI_PADDING che è attivo per impostazione predefinita e sarà sempre in futuro.

Per essere onesti, tendo a RTRIM a scrivere per questo per evitare di avere in lettura che succede lontano più spesso. Deve solo succedere una volta per rovinare la giornata ...

Answer 6

Dipende, ad esempio, dal set di dati Client di Delphi e midas.dll utilizzato (almeno versione 7 e precedente (non so ora) usato per avere bug che se una lunghezza dei dati in un campo Nvarchar era inferiore a quella specificata, essi venivano riempiti.

Non era tanto un problema nel lato del database, ma nei client ci causava non poco . quantità di guai

Answer 7

SQL Server (e molti altri DBMS SQL) veramente schifo quando si tratta di cose come questa:

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

Presumiamo che sia presente una colonna ID o

I valori saranno uguali, avranno la stessa lunghezza, ma in realtà non avranno gli stessi dati. Una concatenazione

select Bar + 'something' from Blah 

e uno avrà uno spazio, l'altro no.