mySQL Problem mit Vergleichsoperatoren

Jump to last post
godlike

godlike

Warp drölf
Veteran
Registriert
13 Juli 2013
Beiträge
14.290
Ort
Topkekistan
Ich steige gerade nicht durch. Habe eine SQL-Abfrage. Vereinfacht sieht diese so aus:

[src=mysql]SELECT tabelle_1.foo, tabelle_2.bar FROM tabelle_1, tabelle_2 WHERE tabelle_2.groesse >= '0.124'[/src]

Hier bekomme ich eine Leere abfrage obwohl es zwei Datensätze in tabelle_2 gibt mit einem Wert bei groesse von 0.124. Ändere ich die Abfrage auf folgendes ab bekomme ich erfolgrei die zwei Datensätze ausgegeben:

[src=mysql]SELECT tabelle_1.foo, tabelle_2.bar FROM tabelle_1, tabelle_2 WHERE tabelle_2.groesse >= '0.123'[/src]

Was ist da los? Der Dateityp ist bei tabelle_2.groesse float falls das was damit zu tun haben könnte...

Viele Grüße

godlike
 
'0.123' ist aber kein float, richtig?

Rundungsproblem bei Konvertierung von Zeichenkette in Fließkomma?

Wenn Du die Hochkommata wegläßt?
 
  • Thread Starter Thread Starter
  • #3
0.124 ist doch eine Fließkommazahl (von -3,402823466[SUP]38[/SUP] bis +3,402823466[SUP]38) [/SUP]oder nicht? Wenn ich die Hochkommata weg lasse erhalte ich auch keinen Treffer... Rundungsproblem kann ich eigentlich ausschließen da der Wert Klartext in der Datenbank steht.
 
Was für einen Datentyp hat die Spalte?
Ist diese in MySQL auch als Double definiert, oder hast du sie als VARCHAR drin?
 
  • Thread Starter Thread Starter
  • #7
Ah ich verstehe! Somit war es Blödsinn hier float zu verwenden wenn ich eh feste Werte nutze. Habe gerade mal versucht Decimal zu nutzen. Ohne Längen-Angabe hat er (10,0) genommen und meine kompletten Werte zerschossen. Hatte zum Glück ein Backup. Ich habe in der Spalte ausschließlich werte von 2 bis 0.0625. Was muss ich also bei Länge abgeben? Habe mal (1,4) Probiert aber er moniert das die erste Zahl größer sein muss als die zweite. Ich dachte das eine steht für vor dem Komma und das andere danach. Oder?
 
Double wäre die übliche Lösung, Du kannst aber auch durchaus Int verwenden ^^
Einfach alles mit Faktor 10000 multiplizieren und die Abfragen bzw. die Verarbeitung entsprechend anpassen.

J.
 
  • Thread Starter Thread Starter
  • #9
Jester schrieb:
Einfach alles mit Faktor 10000 multiplizieren und die Abfragen bzw. die Verarbeitung entsprechend anpassen.
Zum Vergrößern anklicken....
Wie meinen? Die Werte kann/will ich nicht einfach multiplizieren da dann der Sinn verloren geht. Die Komma-Werte stehen für Print-Anzeigengrößen anhand derer bestimmte Boni freigeschaltet/angezeigt werden. 0.25 ist z.B. 1/4 Seite 4c. 0.125 -> 1/8 usw. Wenn ich da jetzt anfange zu multiplizieren gibt das ja keinen Sinn mehr. Oder wie hast du das gemeint?
 
@godlike - das , verschieben

0,25 > 2500
0,0625 > 625

dann ist 1/4 seite noch immer zu erkennen - halt dann 2500 > 10.000 = 1
 
godlike schrieb:
Was muss ich also bei Länge abgeben? Habe mal (1,4) Probiert aber er moniert das die erste Zahl größer sein muss als die zweite. Ich dachte das eine steht für vor dem Komma und das andere danach. Oder?
Zum Vergrößern anklicken....

Nicht denken, sondern die docs lesen ;)
Die linke Zahl steht für die Gesamtlänge aller Ziffern, inklusive der Dezimalstellen. Die rechte Zahl gibt die Länge der Dezimalstellen an.
 
  • Thread Starter Thread Starter
  • #12
@drfuture
Das muss doch auch anders oder? Ich will doch nur den Datentyp ändern um den dussligen Inhalt so übernehmen zu können :o

@X-Coder
Ja ich lese ja schon die ganze Zeit. Allerdings hab ich von SQL weniger Plan. Hab es nun mit Decimal (6,5) probiert und bekomme promt ne Fehlermeldung:

#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '(6,5)) NOT NULL DEFAULT '0'' at line 1
Zum Vergrößern anklicken....

Ok, denke ich weiß woran es liegt. In der DB stehen momentan überall wo keine Anzeige vorliegt 0en drin. Sprich so in etwa:

0
0
0
0.125
0
0.25
0
usw.

Das sollte jetzt wohl so aussehen oder?

0.0000
0.0000
0.0000
0.1250
0.0000
0.2500
0.0000

Wäre höchst nervig, dachte das macht der vielleicht dann von alleine...
 
Zuletzt bearbeitet:
  • Thread Starter Thread Starter
  • #14
Ok, das war mal wieder dämlich :cool: Leider zerhaut er mir auch so meinen Inhalt. es bleibt dann überall nur noch 0, 1 oder 2 übrig. Damit kann ich natürlich nichts anfangen. Auch wenn ich danach neu importiere...
 
du hast nun decimal genommen? - nimm doch mal double wie oben schon erwähnt ist das eigentlich der richtige Datentyp
 
  • Thread Starter Thread Starter
  • #16
Habe es so verstanden das double auch ein Floating-Point Type ist. Hätte ich dann nicht exakt das selbe Problem wie anfangs?
 
You do not have permission to view link please Anmelden or Registrieren


Eigentlich ganz e-z, beim Weg in die Datenbank mutliplizierst Du jeden der betroffenen Werte mit 10000, beim Weg aus der Datenbank heraus dividierst Du wieder durch 10000.

Der Vorteil dabei ist, dass Du innerhalb der Datenbank mit Integern arbeiten kannst, bei denen es das Annäherungs-/Ungenauigkeitsproblem in den Abfragen nicht gibt.

Eine weitere Möglichkeit wäre, jede mögliche Anzeigengröße mit einer Kennzahl zu ersetzen und die dann entsprechend zu verwenden. Also 1/16 Seite = 1, 1/8 Seite = 2 etc. Musst dann halt nur wieder die Abfragelogik anpassen und ggfs die Tabelle mit den eigentlichen Größendefinitionen auslagern.

Gruß, J.
 
  • Thread Starter Thread Starter
  • #19
Nun ja, das Problem ist das ich jedes Jahr zig tausende Datensätze bekomme die aus einer Datenbank für Print stammen. Diese importiere ich dann quasi in meine Online-DB. Sowas würde meinen Mehraufwand einfach enorm steigern. Dann ändere ich lieber im Script mein groesse >= '0.124' auf groesse >= '0.123'. Die Ausgabe stimmt somit immer und ich weiß das es damit keine Probleme geben wird da es keine Anzeigengröße von 0.123 geben wird/kann. Ist zwar unschön aber wohl praktikabler.

Habe es nun aber zwischenzeitlich mal mit double probiert. Danach waren die Werte alle ziemlich verhunzt. Seltsamerweise gab es teilweise Werte mit 10 Nachkommastellen vom runden. Hab dann die Tabelle geleert und neu importiert. Scheint zu klappen bisher. Auch mit der Anfrage :T
 
You do not have permission to view link please Anmelden or Registrieren
: Eine Angabe für die Anzahl der Stellen, eine Angabe wie viele davon nach dem Komma sein sollen. Steht so auch im Link.
Genaue Werte notwendig? -> Nicht float, nicht double, sondern in dem Fall decimal. Oder das Verhalten was Jester vorschlägt im eigenen Datentyp kapseln.

Dann ändere ich lieber im Script mein groesse >= '0.124' auf groesse >= '0.123'. Die Ausgabe stimmt somit immer und ich weiß das es damit keine Probleme geben wird da es keine Anzeigengröße von 0.123 geben wird/kann. Ist zwar unschön aber wohl praktikabler.
Zum Vergrößern anklicken....
imHo keine robuste bzw. ... bzw. annehmbare Lösung.

Nun ja, das Problem ist das ich jedes Jahr zig tausende Datensätze bekomme die aus einer Datenbank für Print stammen.
Zum Vergrößern anklicken....
Wäre vllt gut wenn du präzise definiert was das für Daten sind, also das genaue Format, Wertebereich, Nachkommastellen etc. Für uns und für dich.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben