Sqlserver
 sql >> Database >  >> RDS >> Sqlserver

SQL Server:operatore +(unario) su stringhe non numeriche

Ecco la mia risposta a questa domanda (vedi anche l'aggiornamento alla fine):

No, non esiste un tale operatore unario definito nelle espressioni String. È possibile che si tratti di un bug.

Spiegazione:

L'istruzione data è valida e genera il seguente risultato:

(No column name) 
----------------
ABCDEF
(1 row(s) affected)

che equivale a fare il SELECT istruzione senza utilizzare il + firmare:

SELECT  'ABCDEF'

Essere compilato senza dare errori, anzi essere eseguito con successo, dà l'impressione che + opera come Unary operazione sulla stringa data. Tuttavia, nel T-SQL ufficiale documentazione, non si fa menzione di tale operatore. Infatti, nella sezione intitolata "Operatori di stringa ", + appare in due operazioni String che sono + (String Concatenation) e += (String Concatenation); ma nessuno dei due è un Unary operazione. Inoltre, nella sezione intitolata "Operatori unari ", sono stati introdotti tre operatori, uno solo dei quali è il + (Positive) operatore. Tuttavia, per questo solo che sembra essere rilevante, diventa presto chiaro che anche questo operatore non ha nulla a che fare con valori di stringa non numerici come spiegazione per + (Positive) operatore afferma esplicitamente che questo operatore è applicabile solo per valori numerici:"Restituisce il valore di un'espressione numerica (un operatore unario) ".

Forse, questo operatore è lì per accettare con successo quei valori di stringa che vengono valutati con successo come numeri come quello che è stato utilizzato qui:

SELECT  +'12345'+1

Quando l'istruzione di cui sopra viene eseguita, genera un numero nell'output che è la somma sia della stringa data valutata come un numero che del valore numerico aggiunto ad essa, che è 1 qui ma potrebbe ovviamente essere qualsiasi altro importo:

(No column name) 
----------------
12346
(1 row(s) affected)

Tuttavia, dubito che questa spiegazione sia corretta in quanto solleva le seguenti domande:

In primo luogo, se accettiamo che questa spiegazione sia vera, allora possiamo concludere che espressioni come +'12345' sono valutati in numeri. Se è così, allora perché questi numeri possono apparire nelle funzioni relative alle stringhe come DATALENGTH , LEN , ecc. Potresti vedere una dichiarazione come questa:

  SELECT  DATALENGTH(+'12345')

è abbastanza valido e risulta quanto segue:

 (No column name) 
----------------
5
(1 row(s) affected)

che significa +'12345' viene valutata come una stringa e non come un numero. Come si può spiegare?

In secondo luogo, mentre affermazioni simili con - operatore, come questo:

 `SELECT  -'ABCDE'` 

o anche questo:

`SELECT  -'12345'` 

genera il seguente errore:

Invalid operator for data type. Operator equals minus, type equals varchar.

Perché, non dovrebbe generare un errore per casi simili quando + l'operatore è stato utilizzato in modo errato con un valore di stringa non numerico?

Quindi, queste due domande mi impediscono di accettare la spiegazione che questo è lo stesso + (unary) operatore introdotto nella documentazione per i valori numerici. Poiché non se ne fa menzione da nessun'altra parte, potrebbe essere che sia stato deliberatamente aggiunto alla lingua. Potrebbe essere un bug.

Il problema sembra essere più grave quando vediamo che non viene generato alcun errore nemmeno per istruzioni come questa:

SELECT ++++++++'ABCDE'

Non so se ci sono altri linguaggi di programmazione là fuori che accettano questo tipo di affermazioni. Ma se ci sono, sarebbe bello sapere per quale scopo usano un + (unary) operatore applicato a una stringa. Non riesco a immaginare alcun utilizzo!

AGGIORNAMENTO

Qui dice che questo è stato un bug nelle versioni precedenti ma non verrà risolto a causa della compatibilità con le versioni precedenti:

Dopo alcune indagini, questo comportamento è dovuto alla progettazione poiché + è un operatore unario. Quindi il parser accetta "+ , e in questo caso il '+' viene semplicemente ignorato. La modifica di questo comportamento ha molte implicazioni di compatibilità con le versioni precedenti, quindi non intendiamo cambiarlo e la correzione introdurrà modifiche non necessarie per il codice dell'applicazione.