[MySQL] select nie wyświetla danych float, select float Opcje

[Thuunder]

Czy może mi ktoś podpowiedzieć, czemu nie mogę pobrać wartości pola typu float ... rekord jest w bazie

[SQL] pobierz, plaintext 
SELECT * FROM TABLE WHERE FIELD='0.33'
[SQL] pobierz, plaintext 

Jeśli zrobię

[SQL] pobierz, plaintext 
SELECT * FROM TABLE WHERE FIELD LIKE '%0.33'
[SQL] pobierz, plaintext 

to zadziała, ale chodzi mi o to wyżej...

[thek]

Jeśli drugie działa, to znaczy, że zapewne pole nie jest typu float tylko varchar i jeszcze przed liczbą są jakieś znaki puste. Dlatego wszelkie niewidoczne znaki podpadają pod % choć Ty ich nie widzisz

[maly_swd]

gdzies czytalem ze przy FLOAT nie uzywamy znaku = tylko zakresow, poniewaz jakos dziwnie on to konvertuje.

np 21.40 w bazie ma wartosc 21.3999999999 czy jakos tak.
http://dev.mysql.com/doc/refman/5.0/en/pro...with-float.html tu jest to opisane

[thek]

Czyli znowu wychodzi problem notacji wartości liczb zmiennoprzecinkowych w systemie dziesiętnym. Niedawno był podobny temat na forum, ale tyczył PHP. Jak widać w bazach też to istnieje. Tam był podany dobry sposób moim zdaniem, czyli różnica między liczbą oczekiwaną a tą w bazie nie powinna przekroczyć pewnej określonej, bardzo małej wartości. Ja bym to zapisał jako:
e -> epsilon, wartość dopuszczalna błędu,
y -> nasza liczba oczekiwana(czyli 0.33 przykładowo),
x -> liczba z bazy
Z tego wynika wzór:
e > abs(y - x)

[Thuunder]

Witam,

@thek
Jak rozumiem z tym varcharem to żarcik chyba

Sprawdziłem i faktycznie po zrobieniu round(field,10) wyszło mi 0.3300000131. Lipa...
Jaki w takim razie zrobić typ pola do obliczeń, z różną długością po przecinku, żeby nic się na końcu nie dodawało ?

[thek]

Wcale nie żart Groooomie... Część osób zapisuje float nie jako float czy double w bazie, ale właśnie varchar. Stąd ten wtręt o nim. Co do float to zastanów się nad ewentualnym przejściem na double, który ma większą precyzję. Sam z floatem miałem ten problem i choć double nie rozwiązał problemu, to go zmniejszył do sensownych wartości. Zależy wszystko od tego czy operacje będą wykonywane w bazie czy w php. Osobiście bym się skłaniał przy:
a) jeśli robisz obliczenia w bazie na polach => double
baza tylko przechowuje dane dla operacji w php => varchar
Czemu? Bo przechowywanie wartości jako ciąg znakowy zachowa jego formę w takiej postaci jak chcesz, bez strat związanych z zaokrąglaniem. Ma to jednak tylko sens dla przechowywania niewielkiej ilości danych i na dłuższą metę spowodować może spadek wydajności.
Wybór więc jest tak naprawdę między mniejszym lub większym złem. Problemu by nie było, gdyby liczby mogły zapisywać dane w systemie dziesiętnym. Ale działają w binarnym (choć są pewne ruskie działające w trójkowym, ale to tylko ciekawostka bez znaczenia) i dlatego zawsze będzie problem.

@Thunder: down
Z tym Groooomem to żart słowny z nicka. Thunder to wszak piorun, grzmot, grom. A że masz przeciągnięcie na 'u' to ja przeciągnąłem na 'o' i tak z Thuuuunder zrobił się Grooom

A co do float to nie wiedzieć czemu, ma on bardzo małą dokładność w Mysql. Powinien mieć aż do 24 miejsc po przecinku teoretycznie (tyle można mu nakazać definiując typ), co zresztą jest opisane w manualu, ale widocznie ma jakąś znacznie niższą domyślną wartość parametru precyzji. Zbyt niską do typowych obliczeń. Z tego co przed chwilą zerknąłem do manuala, można jednak definiując typ kolumny nakazać by float miał określoną precyzję, do 53 miejsca włącznie.

Ten post edytował thek 5.11.2009, 16:07:29

[Thuunder]

Groooomie ...o co chodzi ?
Jeśli chodzi o double to daje radę bo nic mi nie dodaje i przy ROUND(field,10) było 0.3300000000

[maly_swd]

ja radzilem sobie w inny sposob:)
1. w bazie dla liczby z 2 miejscami po przecinku trzymam jako np int LICZBA*100
2. jak chce sobie sprawdzic czy to co mam w bazie = sie liczbie ktora sprawdzam to:

select liczba/100 from tabela where liczba=liczba_sprawdzana*100

*wiem, moze glupi sposob ale dziala;)