- Jeśli wykonasz,
SELECT -100/-100*10wynikiem jest0. - Jeśli wykonasz,
SELECT (-100/-100)*10wynikiem jest10. - Jeśli wykonasz,
SELECT -100/(-100*10)wynikiem jest0. - Jeśli wykonasz,
SELECT 100/100*10wynikiem jest10.
BOL stwierdza:
Gdy dwa operatory w wyrażeniu mają ten sam poziom pierwszeństwa operatorów, są one oceniane od lewej do prawej na podstawie ich pozycji w wyrażeniu.
I
Level Operators
1 ~ (Bitwise NOT)
2 * (Multiplication), / (Division), % (Modulus)
3 + (Positive), - (Negative), + (Addition), + (Concatenation), - (Subtraction), & (Bitwise AND), ^ (Bitwise Exclusive OR), | (Bitwise OR)
Czy BOL jest źle, czy coś mi brakuje? Wygląda na -to, że odrzuca (oczekiwany) priorytet.
-to wydaje się być przyczyną „nieprawidłowego” przepływu. Jeśli spróbujesz -100/(-100)*10, otrzymasz wynik 10. wydaje się, że /jest on stosowany względem wartości -w równaniu, a następnie równanie 100*10jest określane. Nie jestem pewien, czy jest to błąd w BOL, ale bardziej niż SQL Server nie zachowuje się zgodnie z oczekiwaniami. Warto poruszyć problem dotyczący sql-docs i sprawdzić, jaka jest ich odpowiedź; być może można by dodać notatkę do dokumentacji informującą o „funkcji”.
SELECT -100/(-100)*10również zwraca 10. Wygląda na to, że -jest traktowany jako -operator, który powinien być zastosowany dopiero po 100*10obliczeniu
A / -B * Cjest A <div> <negate> B <multiply> C. Negacja ma niższy priorytet niż mnożenie, zgodnie z dokumentami, więc wynik jest A / -(B * C). Możesz to zobaczyć wyraźniej, używając stałych zmiennoprzecinkowych: w 12e / -13e * 14eporównaniu 12e / (-13e) * 14ez 12e / 13e * 14e. Powodem, dla którego to nas wytrąca z równowagi, jest to, że generalnie oczekujemy, że jednoargumentowy minus stanie się częścią literału lub przynajmniej będzie miał bardzo wysoki priorytet, ale nie w ten sposób T-SQL Pracuje.