Warum ist 199.96 - 0 = 200 in SQL?

Habe ich einige clients, die sich seltsam Rechnungen. Ich war in der Lage zu isolieren den Kern des Problems:

SELECT 199.96 - (0.0 * FLOOR(CAST(1.0 AS DECIMAL(19, 4)) * CAST(199.96 AS DECIMAL(19, 4)))) -- 200 what the?
SELECT 199.96 - (0.0 * FLOOR(1.0 * CAST(199.96 AS DECIMAL(19, 4)))) -- 199.96
SELECT 199.96 - (0.0 * FLOOR(CAST(1.0 AS DECIMAL(19, 4)) * 199.96)) -- 199.96

SELECT 199.96 - (CAST(0.0 AS DECIMAL(19, 4)) * FLOOR(CAST(1.0 AS DECIMAL(19, 4)) * CAST(199.96 AS DECIMAL(19, 4)))) -- 199.96
SELECT 199.96 - (CAST(0.0 AS DECIMAL(19, 4)) * FLOOR(1.0 * CAST(199.96 AS DECIMAL(19, 4))))                         -- 199.96
SELECT 199.96 - (CAST(0.0 AS DECIMAL(19, 4)) * FLOOR(CAST(1.0 AS DECIMAL(19, 4)) * 199.96))                         -- 199.96

-- It gets weirder...
SELECT (0 * FLOOR(CAST(1.0 AS DECIMAL(19, 4)) * CAST(199.96 AS DECIMAL(19, 4)))) -- 0
SELECT (0 * FLOOR(1.0 * CAST(199.96 AS DECIMAL(19, 4))))                         -- 0
SELECT (0 * FLOOR(CAST(1.0 AS DECIMAL(19, 4)) * 199.96))                         -- 0

-- so... ... 199.06 - 0 equals 200... ... right???
SELECT 199.96 - 0 -- 199.96 ...NO....

Hat jemand eine Ahnung, was zum Teufel ist hier passiert? Ich meine, es hat sicher etwas zu tun mit dem decimal-Datentyp, aber ich kann nicht wirklich wickeln Sie meinen Kopf herum...

Gab es eine Menge Verwirrung darüber, von welchen Datentyp die Anzahl Literale wurden, so entschied ich mich um zu zeigen das wahre line:

PS.SharePrice - (CAST((@InstallmentCount - 1) AS DECIMAL(19, 4)) * CAST(FLOOR(@InstallmentPercent * PS.SharePrice) AS DECIMAL(19, 4))))

PS.SharePrice DECIMAL(19, 4)

@InstallmentCount INT

@InstallmentPercent DECIMAL(19, 4)

Machte ich sicher, dass das Ergebnis jeder operation mit einem Operanden eines anderen Typs als DECIMAL(19, 4) gewirkt wird ausdrücklich vor der Anwendung, um den äußeren Kontext.

Dennoch bleibt das Ergebnis 200.00.

Habe ich jetzt erstellt ein eingekocht Probe, die Sie Jungs können ausführen auf Ihrem computer.

DECLARE @InstallmentIndex INT = 1
DECLARE @InstallmentCount INT = 1
DECLARE @InstallmentPercent DECIMAL(19, 4) = 1.0
DECLARE @PS TABLE (SharePrice DECIMAL(19, 4))
INSERT INTO @PS (SharePrice) VALUES (599.96)

-- 2000
SELECT
  IIF(@InstallmentIndex < @InstallmentCount,
  FLOOR(@InstallmentPercent * PS.SharePrice),
  1999.96)
FROM @PS PS

-- 2000
SELECT
  IIF(@InstallmentIndex < @InstallmentCount,
  FLOOR(@InstallmentPercent * CAST(599.96 AS DECIMAL(19, 4))),
  1999.96)
FROM @PS PS

-- 1996.96
SELECT
  IIF(@InstallmentIndex < @InstallmentCount,
  FLOOR(@InstallmentPercent * 599.96),
  1999.96)
FROM @PS PS

-- Funny enough - with this sample explicitly converting EVERYTHING to DECIMAL(19, 4) - it still doesn't work...
-- 2000
SELECT
  IIF(@InstallmentIndex < @InstallmentCount,
  FLOOR(@InstallmentPercent * CAST(199.96 AS DECIMAL(19, 4))),
  CAST(1999.96 AS DECIMAL(19, 4)))
FROM @PS PS

Jetzt habe ich etwas...

-- 2000
SELECT
  IIF(1 = 2,
  FLOOR(CAST(1.0 AS decimal(19, 4)) * CAST(199.96 AS DECIMAL(19, 4))),
  CAST(1999.96 AS DECIMAL(19, 4)))

-- 1999.9600
SELECT
  IIF(1 = 2,
  CAST(FLOOR(CAST(1.0 AS decimal(19, 4)) * CAST(199.96 AS DECIMAL(19, 4))) AS INT),
  CAST(1999.96 AS DECIMAL(19, 4)))

Was solls - Etage soll eine Ganzzahl zurück sowieso. Was ist denn hier Los? 😀

Ich denke, dass ich es nun geschafft wirklich Kochen es nach unten, um die Wesen 😀

-- 1.96
SELECT IIF(1 = 2,
  CAST(1.0 AS DECIMAL (36, 0)),
  CAST(1.96 AS DECIMAL(19, 4))
)

-- 2.0
SELECT IIF(1 = 2,
  CAST(1.0 AS DECIMAL (37, 0)),
  CAST(1.96 AS DECIMAL(19, 4))
)

-- 2
SELECT IIF(1 = 2,
  CAST(1.0 AS DECIMAL (38, 0)),
  CAST(1.96 AS DECIMAL(19, 4))
)

199.96 -0 nicht gleich 200. Alle diejenigen wirft, und die Böden mit impliziten Konvertierungen, die floating-point und zurück sind doch garantiert in der Folge der Präzision Verlust.
was ist der Typ von 199.96 durch die Art und Weise? Es ist nicht eine Dezimalzahl. Es konvertiert implizit einen Typ, der kompatibel mit den anderen Operanden
199.96 hat der Typ decimal(19, 4) in der realen Probe.
nur, wenn es kam aus einer Tabelle. Als literal in einem Ausdruck ist es wahrscheinlich eine float
Die Antwort von Tapakah Ua (mit meinen änderungen) erklärt, warum das neue sample nicht funktioniert, selbst wenn alles Stimmen, um decimal(19,4). Sql Server mutieren die Typen während der Arithmetik, und in diesem Fall das Ergebnis von der Art der mutation die überläufe der größten Art Sql-Server unterstützt, welche Kräfte es zu entfernen, die Waage. So dass man am Ende bis Rundung die 199.96 Wert.
Oh... und Floor() hat nicht kehren Sie ein int. Es gibt die gleiche Art wie die ursprüngliche Ausdruck, mit dem dezimalen Teil entfernt. Für den rest, der IIF() Funktion führt die Art mit der höchsten Priorität (docs.microsoft.com/en-us/sql/t-sql/functions/...). Also das 2. Beispiel, wo Sie cast zu int, die höhere Priorität ist die einfache Besetzung als numeric(19,4).
Tolle Antwort (wer wusste, Sie könnte prüfen, Metadaten eines sql-Variante?) aber ich 2012 die erwarteten Ergebnisse erhalten (199.96).
MS SQL Server und Sybase beide nennen Ihre Sprache T-SQL-denn an einer Stelle waren Sie arbeiten zusammen auf der gleichen Basis-Produkt. Siehe diese MS blog-post für details.
Ich bin nicht allzu vertraut mit MS SQL, aber ich muss sagen, dass der Blick auf all diese cast-Operationen und so weiter schnell meine Aufmerksamkeit gefangen.. also ich muss link, denn niemand sollte jemals mit floating-point-Typen auf die Währung.
Nicht verwenden, floating-point-zahlen, mit Geld umzugehen.
Und für diese Angelegenheit, vermeiden Sie SQL Server, wenn möglich 🙂
Keine floating-point-Datentypen verwendet, die in die Frage. Und ich denke, dass keine floating-point-operation verwendet wird, in jedem Beispiel.
Sind nicht die 1.0s angefangen als floating-point-zahlen, bevor die as decimal(...) Teil?
ein 1.0 ist eine dezimale Konstante 1e0 ist eine float-Konstante.

InformationsquelleAutor Silverdust | 2018-07-20

77

Brauche ich vom Auspacken ein bisschen, damit ich sehen kann, was Los ist:
```
SELECT 199.96 - 
    (
        0.0 * 
        FLOOR(
            CAST(1.0 AS DECIMAL(19, 4)) * 
            CAST(199.96 AS DECIMAL(19, 4))
        )
    ) 
```
Nun wollen wir sehen, genau das, was Arten von SQL Server für jede Seite der Subtraktion:
```
SELECT  SQL_VARIANT_PROPERTY (199.96     ,'BaseType'),
    SQL_VARIANT_PROPERTY (199.96     ,'Precision'),
    SQL_VARIANT_PROPERTY (199.96     ,'Scale')

SELECT  SQL_VARIANT_PROPERTY (0.0 * FLOOR(CAST(1.0 AS DECIMAL(19, 4)) * CAST(199.96 AS DECIMAL(19, 4)))  ,'BaseType'),
    SQL_VARIANT_PROPERTY (0.0 * FLOOR(CAST(1.0 AS DECIMAL(19, 4)) * CAST(199.96 AS DECIMAL(19, 4)))  ,'Precision'),
    SQL_VARIANT_PROPERTY (0.0 * FLOOR(CAST(1.0 AS DECIMAL(19, 4)) * CAST(199.96 AS DECIMAL(19, 4)))  ,'Scale')
```
Ergebnisse:
```
numerisch 5 2 
numerische 38 1 
```
So 199.96 ist numeric(5,2) und mehr Floor(Cast(etc)) ist numeric(38,1).

Den Regeln für die resultierende Genauigkeit und Skalierung von einer Subtraktion (dh: e1 - e2) wie folgt Aussehen:

Präzision: max(s1, s2) + max(p1-s1, p2-s2) + 1

Maßstab: max(s1, s2)

Auswertet, wie diese:

Präzision: max(1,2) + max(38-1, 5-2) + 1 => 2 + 37 + 1 => 40

Maßstab: max(1,2) => 2

Können Sie auch die link Regeln, um herauszufinden, wo die numeric(38,1) kam in den ersten Platz (Tipp: man multipliziert zwei Präzisions-19-Werte).

Aber:
- Das Ergebnis die Genauigkeit und die Dezimalstellen haben ein absolutes maximum von 38. Wenn ein Ergebnis ist die Präzision größer als 38 ist, ist es reduziert auf 38, und die
  entsprechende Skala wird reduziert, um zu versuchen, um zu verhindern, dass die integraler Bestandteil der
  ein Ergebnis abgeschnitten wird. In einigen Fällen, wie etwa der Multiplikation, oder
  division, Maßstab Faktor nicht reduziert werden, um zu halten dezimal
  Präzision, obwohl die overflow-Fehler ausgelöst werden kann.
Oops. Die Präzision ist 40. Wir haben zu reduzieren, und da die Verringerung der Präzision sollte immer schneiden Sie die am wenigsten signifikanten Ziffern, bedeutet die Reduzierung der Skala, zu. Endgültigen Typ für den Ausdruck wird numeric(38,0), die für 199.96 Runden zu 200.

Können Sie wahrscheinlich dieses Problem beheben durch Umzug und die Zusammenlegung der CAST() Vorgänge aus dem inneren des großen Ausdruck eine CAST() um den gesamten Ausdruck Ergebnis. Also diese:
```
SELECT 199.96 - 
    (
        0.0 * 
        FLOOR(
            CAST(1.0 AS DECIMAL(19, 4)) * 
            CAST(199.96 AS DECIMAL(19, 4))
        )
    ) 
```
Wird:
```
SELECT CAST( 199.96 - ( 0.0 * FLOOR(1.0 * 199.96) ) AS decimial(19,4))
```
Könnte ich sogar entfernen Sie das äußere werfen, wie gut.

Lernen wir hier, die wir wählen sollten Typen übereinstimmen, die Genauigkeit und die Dezimalstellen haben wir eigentlich jetzt, anstatt das erwartete Ergebnis. Es macht keinen Sinn, einfach zu gehen, für die große Präzision der zahlen, da SQL Server mutieren diejenigen Arten, die während der arithmetischen Operationen zu vermeiden, dass die überläuft.

Weitere Informationen:
InformationsquelleAutor Stanislav Kundii

Halten Sie ein Auge auf Datentypen beteiligt, für die folgende Aussage:

SELECT 199.96 - (0.0 * FLOOR(CAST(1.0 AS DECIMAL(19, 4)) * CAST(199.96 AS DECIMAL(19, 4))))

NUMERIC(19, 4) * NUMERIC(19, 4) ist NUMERIC(38, 7) (siehe unten)
- FLOOR(NUMERIC(38, 7)) ist NUMERIC(38, 0) (siehe unten)
0.0 ist NUMERIC(1, 1)
- NUMERIC(1, 1) * NUMERIC(38, 0) ist NUMERIC(38, 1)
199.96 ist NUMERIC(5, 2)
- NUMERIC(5, 2) - NUMERIC(38, 1) ist NUMERIC(38, 1) (siehe unten)

Dies erklärt, warum Sie am Ende mit 200.0 (eine Stelle nach dem Dezimaltrennzeichen, nicht null) statt 199.96.

Hinweise:

BODEN gibt die größte ganze Zahl kleiner als oder gleich dem angegebenen numerischen Ausdruck und Ergebnis hat den gleichen Typ wie der input. Es gibt INT für INT, FLOAT für FLOAT-und NUMERIC(x, 0), NUMERIC(x, y).

Laut der Algorithmus:

Operation | Result precision                    | Result scale*
e1 * e2   | p1 + p2 + 1                         | s1 + s2
e1 - e2   | max(s1, s2) + max(p1-s1, p2-s2) + 1 | max(s1, s2)
* Das Ergebnis die Genauigkeit und die Dezimalstellen haben ein absolutes maximum von 38. Wenn
ein Ergebnis ist die Präzision größer als 38 ist, ist es reduziert auf 38, und die
entsprechende Skala wird reduziert, um zu versuchen, um zu verhindern, dass die integraler Bestandteil der
ein Ergebnis abgeschnitten wird.

Die Beschreibung enthält auch die details, wie genau die Waage ist reduziert von innen addition und Multiplikation Operationen. Basierend auf dieser Beschreibung:

NUMERIC(19, 4) * NUMERIC(19, 4) ist NUMERIC(39, 8) und gespannt zu NUMERIC(38, 7)
NUMERIC(1, 1) * NUMERIC(38, 0) ist NUMERIC(40, 1) und gespannt zu NUMERIC(38, 1)
NUMERIC(5, 2) - NUMERIC(38, 1) ist NUMERIC(40, 2) und gespannt zu NUMERIC(38, 1)

Hier ist mein Versuch, die zur Umsetzung des Algorithmus in JavaScript. Ich habe überprüft die Ergebnisse mit SQL Server. Es beantwortet die Wesen Teil Ihrer Frage.

JS:

//https://docs.microsoft.com/en-us/sql/t-sql/data-types/precision-scale-and-length-transact-sql?view=sql-server-2017

function numericTest_mul(p1, s1, p2, s2) {
  //e1 * e2
  var precision = p1 + p2 + 1;
  var scale = s1 + s2;

  //see notes in the linked article about multiplication operations
  var newscale;
  if (precision - scale < 32) {
    newscale = Math.min(scale, 38 - (precision - scale));
  } else if (scale < 6 && precision - scale > 32) {
    newscale = scale;
  } else if (scale > 6 && precision - scale > 32) {
    newscale = 6;
  }

  console.log("NUMERIC(%d, %d) * NUMERIC(%d, %d) yields NUMERIC(%d, %d) clamped to NUMERIC(%d, %d)", p1, s1, p2, s2, precision, scale, Math.min(precision, 38), newscale);
}

function numericTest_add(p1, s1, p2, s2) {
  //e1 + e2
  var precision = Math.max(s1, s2) + Math.max(p1 - s1, p2 - s2) + 1;
  var scale = Math.max(s1, s2);

  //see notes in the linked article about addition operations
  var newscale;
  if (Math.max(p1 - s1, p2 - s2) > Math.min(38, precision) - scale) {
    newscale = Math.min(precision, 38) - Math.max(p1 - s1, p2 - s2);
  } else {
    newscale = scale;
  }

  console.log("NUMERIC(%d, %d) + NUMERIC(%d, %d) yields NUMERIC(%d, %d) clamped to NUMERIC(%d, %d)", p1, s1, p2, s2, precision, scale, Math.min(precision, 38), newscale);
}

function numericTest_union(p1, s1, p2, s2) {
  //e1 UNION e2
  var precision = Math.max(s1, s2) + Math.max(p1 - s1, p2 - s2);
  var scale = Math.max(s1, s2);

  //my idea of how newscale should be calculated, not official
  var newscale;
  if (precision > 38) {
    newscale = scale - (precision - 38);
  } else {
    newscale = scale;
  }

  console.log("NUMERIC(%d, %d) + NUMERIC(%d, %d) yields NUMERIC(%d, %d) clamped to NUMERIC(%d, %d)", p1, s1, p2, s2, precision, scale, Math.min(precision, 38), newscale);
}

/*
 * first example in question
 */

//CAST(1.0 AS DECIMAL(19, 4)) * CAST(199.96 AS DECIMAL(19, 4))
numericTest_mul(19, 4, 19, 4);

//0.0 * FLOOR(...)
numericTest_mul(1, 1, 38, 0);

//199.96 * ...
numericTest_add(5, 2, 38, 1);

/*
 * IIF examples in question
 * the logic used to determine result data type of IIF /CASE statement
 * is same as the logic used inside UNION operations
 */

//FLOOR(DECIMAL(38, 7)) UNION CAST(1999.96 AS DECIMAL(19, 4)))
numericTest_union(38, 0, 19, 4);

//CAST(1.0 AS DECIMAL (36, 0)) UNION CAST(1.96 AS DECIMAL(19, 4))
numericTest_union(36, 0, 19, 4);

//CAST(1.0 AS DECIMAL (37, 0)) UNION CAST(1.96 AS DECIMAL(19, 4))
numericTest_union(37, 0, 19, 4);

//CAST(1.0 AS DECIMAL (38, 0)) UNION CAST(1.96 AS DECIMAL(19, 4))
numericTest_union(38, 0, 19, 4);

InformationsquelleAutor Salman A

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.

Weitere Informationen: