SQL server 'wie' gegen ein float-Feld produziert inkonsistente Ergebnisse

Ich bin mit LIKE zurückkehren passenden numerischen Ergebnisse gegen ein float-Feld. Es scheint, dass, wenn es sind mehr als 4 stellen Links von der Dezimalstelle, Werte, die mit meinem Suchbegriff auf der rechten Seite der Dezimalstelle sind nicht zurückgekehrt. Hier ist ein Beispiel zur Veranschaulichung der situation:

CREATE TABLE number_like_test (
  num [FLOAT] NULL
)

INSERT INTO number_like_test (num) VALUES (1234.56)
INSERT INTO number_like_test (num) VALUES (3457.68)
INSERT INTO number_like_test (num) VALUES (13457.68)
INSERT INTO number_like_test (num) VALUES (1234.76)
INSERT INTO number_like_test (num) VALUES (23456.78)

SELECT num FROM number_like_test
WHERE num LIKE '%68%'

Dass die Abfrage nicht zurück, wird der Datensatz mit dem Wert von 12357.68, aber es tut Rückkehr der Datensatz mit dem Wert von 3457.68. Auch die Ausführung der Abfrage mit 78 statt 68 nicht zurück 23456.78 aufnehmen, aber mit 76 gibt die 1234.76 aufnehmen.

So, die Frage: warum die eine größere Zahl bewirkt, dass diese Ergebnisse zu ändern? Wie kann ich meine Abfrage die erwarteten Ergebnisse erhalten?

  • verwenden Sie nicht LIKE gegen zahlen. Es ist ein string-Vergleich für strings verwendet.
  • was ist, wenn die numerischen Werte sind cast strings?
  • Sie könnte das tun, aber ich Schätze, der Grund, warum auf der Erde Sie?
  • Ich muss einige Benutzer Suche Artikel gegen numerische Felder, auf denen die Ergebnisse, die Sie wollen, mit 'wie'. Was ist die alternative?
  • Wie ist nicht das problem hier. Es kann funktionieren mit zahlen, implizite Konvertierung in string auftreten. Float ist das problem, es ist annähernd Datentyp - Schalter sollte man dezimal oder zumindest wirken zu dezimal, bevor Sie den Vergleich.
  • sqlfiddle.com/#!6/d41d8/4730
  • ja, du hast Recht. Die Antwort hier(stackoverflow.com/questions/15950705/...), scheint für mich arbeiten.

InformationsquelleAutor rosscj2533 | 2013-06-12
  1. 5

    Den like Betreiber erfordert eine Zeichenfolge als left-hand-Wert. Laut der Dokumentation, die eine Konvertierung von float zu varchar können mehrere Stile:

    Value         Output
0 (default)   A maximum of 6 digits. Use in scientific notation, when appropriate.
1             Always 8 digits. Always use in scientific notation.
2             Always 16 digits. Always use in scientific notation.

    Den Standard-Stil funktioniert gut für die sechs Ziffern in 3457.68, aber nicht für die sieben Ziffern in 13457.68. 16-stellig statt 6, Sie könnte verwenden convert angeben und Stil 2. Stil 2 stellt eine Zahl dar wie 3.457680000000000e+003. Aber das würde nicht funktionieren, für die ersten zwei Ziffern, und Sie erhalten eine unerwartete +003 Exponenten für frei.

    Der beste Ansatz ist wahrscheinlich eine Umwandlung von float zu decimal. Konvertierung können Sie angeben, das Ausmaß und Präzision. Mit Skala 20 und Präzision 10, der Schwimmer wird dargestellt als 3457.6800000000:

    where   convert(decimal(20,10), num) like '%68%'
    • Gute Antwort, sogar mit es arbeiten mit dem dezimal konvertieren, diese füllt sich die Frage, warum es nicht funktioniert aufgrund der Anzahl der Ziffern. Ist die äußere konvertiert zu varchar wirklich notwendig?
    • Guter Punkt, es sieht aus wie das äußere konvertieren ist nicht erforderlich. Die implizite Konvertierung von decimal zu varchar nicht drop Ziffern.
    • Super Antwort! 5 Jahre später dieser nur mich gerettet, so viel Zeit und Kopfschmerzen lol
    InformationsquelleAutor Andomar
  2. 2

    Wenn Sie vergleichen die Anzahl mit WIE es implizit in eine Zeichenfolge konvertiert und dann abgestimmt


    Das problem hier ist, dass float-Zahl ist nicht genau und wenn es umgewandelt wird, können Sie bekommen

    13457.679999999999999 statt 13457.68

    So begeisterter dies ausdrücklich format Zahl im entsprechenden format(nicht sicher, wie dies in sql server, aber es wird so etwas wie)

    SELECT num FROM number_like_test
WHERE Format("0.##",num) LIKE '%68%'
    InformationsquelleAutor VitaliyG
  3. 2

    Konvertierung zum string rundet Ihre Werte. Beide CONVERT und CAST haben das gleiche Verhalten.

    SELECT cast(num as nvarchar(50)) as s
FROM number_like_test

    Oder

    SELECT convert(nvarchar(50), num) as s
FROM number_like_test

    Ergebnisse:

    1234.56
3457.68
13457.7
1234.76
23456.8

    Müssen Sie die STR Funktion und korrekte Parameter-format, um zu versuchen, um Ihre Ergebnisse. Zum Beispiel,

    SELECT STR(num, 10, 2) as s
FROM number_like_test

    gibt:

       1234.56
   3457.68
  13457.68
   1234.76
  23456.78
    • Aber mithilfe dieser Werte (cast oder convert) in die where-Klausel mit der wie noch gibt falsche Ergebnisse. Ich brauche zu werfen, um dezimal (wie NenadZivkovic kommentiert), weil die Präzision der float-Datentyp.
    • Dein edit funktioniert ordnungsgemäß in der where-Klausel. Danke.
    • Ja, das ist es, was ich zu sagen versuchte. Umwandlung einer Dezimalzahl ist wohl der richtige Weg zu gehen, aber mit STR, mit den richtigen Parameter-format ist ebenfalls möglich.
    InformationsquelleAutor ken
  4. 2

    Ziemlich gut gelöst, aber man braucht sich nur den CAST einmal, nicht zweimal wie die anderen Antwort erläutert, WIE kümmert sich um die string-Konvertierung:

    SELECT *
FROM number_like_test
WHERE CAST(num AS DECIMAL(12,6)) LIKE '%68%'

    Und hier ist ein SQL Fiddle zeigt das rundungsverhalten: SQL Fiddle

    InformationsquelleAutor Hart CO
  5. 1

    Es ist wahrscheinlich, weil ein FLOAT-Datentyp stellt eine floating-point-Zahl das ist eine Annäherung der Anzahl und sollten nicht herangezogen werden, für genaue Vergleiche.

    Wenn Sie brauchen, um eine Suche beinhaltet, dass der float-Wert müssten Sie entweder speichern Sie es in einen decimal-Datentyp (was hält die genaue Zahl) oder konvertieren Sie es in ein varchar mit so etwas wie die STR () - Funktion

    InformationsquelleAutor Rich Andrews
Schreibe einen Kommentar