SQL server 2005 numerische Präzision Verlust

Debuggen einige Finanz-bezogene SQL-code gefunden, der ein seltsames Problem mit numerischen(24,8) Mathematik Präzision.

Ausführen der folgenden Abfrage auf Ihre MSSQL, Sie würden Holen Sie sich A + B * C-Ausdruck Ergebnis 0.123457

WÄHLEN SIE EIN,
B,
C,
A + B * C
AUS
(
SELECT CAST(0.12345678 ALS NUMERIC(24,8)) ALS,
CAST(0 AS NUMERIC(24,8)) WIE B,
CAST(500, DIE ALS NUMERISCHE(24,8)) ALS C
) T

So dass wir verloren haben 2 bedeutende Symbole. Versuchen, um dieses Problem in unterschiedlicher Weise bekam ich, dass die Umstellung von der Mittelstufe Multiplikation Ergebnis (die Null!) numeric (24,8) würde funktionieren.

Und schließlich eine Lösung habe. Aber ich hace eine Frage - warum MSSQL so verhält und welche Umbauten tatsächlich bewahrheitet in meinem Beispiel?

InformationsquelleAutor Ilya Komakhin | 2008-09-24
  1. 7

    Nur als Ergänzung zu den Typ float ist ungenau, Multiplikation mit der Dezimalzahl-Typen können ungenau sein (oder zu Ungenauigkeiten) wenn Sie mehr als die Präzision. Sehen Datentyp-Konvertierung und decimal und numeric.

    Da Sie multipliziert NUMERIC(24,8) und NUMERIC(24,8) - und SQL-Server überprüft nur den Typ, nicht auf den Inhalt, wird es wahrscheinlich versuchen Sie das Potenzial 16 nicht-dezimalen Ziffern (24 - 8), wenn Sie können nicht speichern Sie alle 48 Ziffern der Präzision (max 38). Kombinieren Sie zwei von Ihnen, Sie 32 nicht-dezimalen Ziffern, die Sie verlässt mit nur 6 Dezimalstellen (38 - 32).

    Somit die ursprüngliche Abfrage 

    SELECT A, B, C, A + B * C
FROM ( SELECT CAST(0.12345678 AS NUMERIC(24,8)) AS A,
  CAST(0 AS NUMERIC(24,8)) AS B,
  CAST(500 AS NUMERIC(24,8)) AS C ) T

    reduziert sich auf

    SELECT A, B, C, A + D
FROM ( SELECT CAST(0.12345678 AS NUMERIC(24,8)) AS A,
  CAST(0 AS NUMERIC(24,8)) AS B,
  CAST(500 AS NUMERIC(24,8)) AS C,
  CAST(0 AS NUMERIC(38,6)) AS D ) T

    Wieder, zwischen NUMERIC(24,8) und NUMERIC(38,6) SQL Server zu speichern versuchen, das Potenzial 32 Ziffern von nicht-dezimalen, so A + D reduziert sich auf 

    SELECT CAST(0.12345678 AS NUMERIC(38,6))

    gibt Sie 0.123457 nach der Rundung.

    • Sie meinte NUMERIC(32,6)) ?? Wenn die Summe muss 38
    • Bitte die links Lesen und verstehen, was die beiden zahlen bedeuten.
    • Sie sagen, dass bei der Multiplikation zweier zahlen (24,8) der server wird versuchen, Sie zu retten (16 bit) und produzieren (32,6) , wie kommt es zu einem 38,6? Dank
    • In NUMERIC(p, s), p steht für Präzision die Summe die Anzahl der Ziffern. So in NUMERIC(24, 8) gibt es 16 Ziffern von nicht-Dezimalzahlen. Keine bits. Wieder, Lesen Sie sich bitte den link in der msdn-Dokumentation.
    InformationsquelleAutor Eugene Yokota
  2. 0

    Nach der Logik hingewiesen hat, eed3si9n und das, was Sie gesagt in Ihrer Frage, es scheint, dass der beste Ansatz, wenn dabei die Mathematik-Operationen zu extrahieren und Sie in eine Funktion und zusätzlich die Genauigkeit festlegen nach jeder operation,

    Es in diesem Fall die Funktion könnte so Aussehen:

    create function dbo.myMath(@a as numeric(24,8), @b as numeric(24,8), @c as numeric(24,8))
returns  numeric(24,8)
as
begin 
    declare @d as numeric(24,8)
    set @d = @b* @c
    return @a + @d
end
    • Dieser Ansatz kann nicht lösen das Problem der SQL-Server hacken off die dezimale Teile. Speichern Sie die dezimalen Teile, kann es notwendig sein, zu werfen, um @a und @b in die Doppel.
    • Danke, ich werde es im Kopf behalten bei der Arbeit auf einige der Präzision der Mathematik in SQL, So weit habe ich nicht verwenden müssen, aber es ist gut jetzt, dass es einige Aspekte zu berücksichtigen
    InformationsquelleAutor kristof
  3. 0

    Trotz allem, was es sagt, auf Genauigkeit, Dezimalstellen und Länge (Transact-SQL). Ich glaube, es ist auch die Anwendung mindestens 'scale (Anzahl Nachkommastellen) von 6, um die daraus resultierenden NUMERISCHEN Typs, die für die Multiplikation das gleiche wie für division etc.

    InformationsquelleAutor phoenix10k
Schreibe einen Kommentar