Sqlserver
 sql >> Datenbank >  >> RDS >> Sqlserver

SQL Server:+(unärer) Operator für nicht-numerische Strings

Hier ist meine eigene Antwort auf diese Frage (siehe auch das Update am Ende):

Nein, es gibt keinen solchen unären Operator, der für die String-Ausdrücke definiert ist. Es ist möglich, dass dies ein Fehler ist.

Erklärung:

Die gegebene Anweisung ist gültig und erzeugt das folgende Ergebnis:

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

was dem SELECT entspricht -Anweisung ohne Verwendung von + Zeichen:

SELECT  'ABCDEF'

Ohne Fehler kompiliert zu werden, tatsächlich erfolgreich ausgeführt zu werden, erweckt den Eindruck, dass + arbeitet als Unary Operation auf der angegebenen Zeichenfolge. Allerdings im offiziellen T-SQL Dokumentation wird ein solcher Operator nicht erwähnt. Genauer gesagt im Abschnitt „String-Operatoren ", + erscheint in zwei String-Operationen, die + (String Concatenation) sind und += (String Concatenation); aber beides ist kein Unary Betrieb. Außerdem im Abschnitt „Unäre Operatoren " wurden drei Operatoren eingeführt, von denen nur einer der + (Positive) ist Operator. Allerdings wird für diesen einzigen scheinbar relevanten Operator schnell klar, dass auch dieser Operator nichts mit nicht-numerischen Stringwerten als Erklärung für + (Positive) zu tun hat Der Operator gibt ausdrücklich an, dass dieser Operator nur für numerische Werte gilt:"Gibt den Wert zurück eines numerischen Ausdrucks (ein unärer Operator) ".

Vielleicht ist dieser Operator dazu da, erfolgreich solche Zeichenfolgewerte zu akzeptieren, die erfolgreich als Zahlen ausgewertet werden, wie der hier verwendete:

SELECT  +'12345'+1

Wenn die obige Anweisung ausgeführt wird, generiert sie eine Zahl in der Ausgabe, die die Summe sowohl der als Zahl bewerteten gegebenen Zeichenfolge als auch des hinzugefügten numerischen Werts ist, der 1 ist hier, aber es könnte natürlich jeder andere Betrag sein:

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

Ich bezweifle jedoch, dass diese Erklärung richtig ist, da sie die folgenden Fragen aufwirft:

Erstens, wenn wir akzeptieren, dass diese Erklärung wahr ist, dann können wir daraus schließen, dass Ausdrücke wie +'12345' werden zu Zahlen ausgewertet. Wenn ja, warum können diese Zahlen dann in den String-bezogenen Funktionen wie DATALENGTH erscheinen , LEN usw. Sie könnten eine Anweisung wie diese sehen:

  SELECT  DATALENGTH(+'12345')

ist ziemlich gültig und ergibt das Folgende:

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

was bedeutet +'12345' wird als String und nicht als Zahl ausgewertet. Wie ist das zu erklären?

Zweitens, während ähnliche Anweisungen mit - Operator, wie dieser:

 `SELECT  -'ABCDE'` 

oder sogar das:

`SELECT  -'12345'` 

erzeugen den folgenden Fehler:

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

Warum sollte es nicht einen Fehler für ähnliche Fälle erzeugen, wenn + Operator wurde fälschlicherweise mit einem nicht numerischen Zeichenfolgenwert verwendet?

Diese beiden Fragen hindern mich also daran, die Erklärung zu akzeptieren, dass dies derselbe + (unary) ist Operator, der in der Dokumentation für numerische Werte eingeführt wurde. Da es nirgendwo anders erwähnt wird, könnte es sein, dass es der Sprache absichtlich hinzugefügt wurde. Kann ein Fehler sein.

Das Problem scheint schwerwiegender zu sein, wenn wir sehen, dass auch für Anweisungen wie diese kein Fehler generiert wird:

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

Ich weiß nicht, ob es andere Programmiersprachen gibt, die diese Art von Anweisungen akzeptieren. Aber wenn ja, wäre es schön zu wissen, für welche(n) Zweck(e) sie einen + (unary) verwenden Operator auf eine Zeichenfolge angewendet. Ich kann mir keine Verwendung vorstellen!

AKTUALISIEREN

Hier heißt es, dass dies ein Fehler in früheren Versionen war, aber wegen Abwärtskompatibilität nicht behoben wird:

Nach einigen Untersuchungen ist dieses Verhalten beabsichtigt da + ein unärer Operator ist. Der Parser akzeptiert also "+", und das "+" wird in diesem Fall einfach ignoriert. Das Ändern dieses Verhaltens hat viele Auswirkungen auf die Abwärtskompatibilität, daher beabsichtigen wir nicht, es zu ändern, und der Fix wird unnötige Änderungen für den Anwendungscode einführen.