Sklep internetowy - groszowy szał Opcje

[wujek2009]

Cześć.

W jaki sposób podchodzicie do przechowywania cen produktów w bazie danych i późniejsze ich wyświetlanie oraz kalkulowanie (odejmowanie, dodawanie) - tak, aby po zaokrągleniu był wynik ten sam co na kalkulatorze. Number Format zaokrągla w zły sposób w konsekwencji ceny nie nakładają się na siebie.

[nospor]

Ale po co ci do dodawanie czy odejmowania number format? Jesli masz
2.34 + 4.21 to po co tutaj number format? Number format to se mozesz co najwyzej uzyc przy wyswietleniu wyniku, a nie podczas wyliczania wyniku

Poza tym, by uniknac ewentualnych problemow z dzialaniem na liczbach rzeczywistych, warto trzymac kwoty w bazie jako INT - liczba groszy, a nie zlotowek

[wujek2009]

Problem w tym, że cały czas zaokrągla groszem w górę.

[PHP] pobierz, plaintext 
$a = 10.48888;
$b = 2;
 
$wynik = $a+$b;
var_dump(number_format($wynik, 2));
[PHP] pobierz, plaintext 

Wynik php: 12.49
Wynik, który mnie interesuje: 12.48

Jak zmienię zmienną $a na "10.48" bez tego dłuższego ogonu to wszystko jest w porządku. Więc szukamy funkcji, która UTNIE mi reszte cyfr po przecinku (dwa miejsca), ale nie będzie zaokrąglać jak 48 to zaokrągli do 49, itd..

[nospor]

Co ty masz za sklep, ze trzymasz w nim wartosci 10.48888 ? Jesli to jest wynik jakis obliczen, to po zaokrągleniu powinnno byc wlasnie 10.49 a nie 10.48

Jesli nadal sie upierasz na niezaokrąglaniu, to zrzutuj liczbe na stringa i srob poprostu substr()

[memory]

http://interpretacja-podatkowa.pl/interpre...lanie-kwot.html

[markuz]

Proponuję ceil. W komentarzach znajdziesz funkcję ceil_dec która powinna Ci wystarczyć.

[widmo_91]

Przede wszystkim w bazie kwoty powinieneś przechowywać jako typ DECIMAL z 2 miejscami po przecinku a nie jakieś FLOATY.

Jeżeli problem nadal by występował z jakiegoś powodu to zapoznaj się z funkcją floor floor w pierwszym komentarzu masz rozwiązanie dokładnie twoje problemu.

[tczajka]

Ja ostatnimi czasy zawsze kwoty w bazie przechowuję z dokładnością do 4 miejsc po przecinku - właśnie przez wzgląd na dokładność przy np przeliczaniu. a Wyświetlam oczywiście zaokrąglone do 2 miejsc po przecinku.

[widmo_91]

@up
gratuluję pomysłowości

Jakby nie było typu decimal i podobnych to bym prędzej używał liczb całkowitych i przy wyciąganiu dzielił to przez 100, przynajmniej można by było wtedy skorzystać z operatora = w zapytaniach.

[Pyton_000]

Przede wszystkim w bazie kwoty powinieneś przechowywać jako typ DECIMAL z 2

Tak o ile zostaną zaokrąglone w odpowiedni sposób. Dlatego trzymanie w bazie kwot do 4 miejsc po przecinku jest dla mnie jak najbardziej odpowiednie.
Jest może troszkę większy nakład pracy i czujności na operowaniu tego typu danymi ale potem jest pewność że wszystko sie zgadza.

@up i nie wiem co Cię tak szokuje w większej ilości miejsc po ,

[widmo_91]

@up W programowaniu/projektowaniu dobrą cechą jest nakładanie sobie ograniczeń dzięki czemu program jest mniej podatny na błędy.

Na pewno istnieją sytuację gdzie należy przechowywać większą liczbę miejsc po przecinku np. przy przeliczenia podatku VAT. Tylko, że nie jest to kwestia wyboru i ostrożności pisania kodu tylko konieczność. Na pewno nie ma takiej reguły.

Na stronie i tak trzeba podać cenę z 2 miejscami, gdyby była sytuacja, że przechowywane są 4 miejsca i cena 2 różnych produktów wynosi 1,00 to po ich dodaniu i zaokrągleniu (zależnie od sposobu zaokrąglania) moglibysmy otrzymać cenę różną o grosz, gdyby zaokrąglać te produkty za każdym razem z osobna (żeby otrzymać prawidłową sumą) to po co trzymać więcej miejsc i dodawać sobie roboty.

[Pyton_000]

@up
Jeżeli będziesz miał popisane metody dla produktu które przeliczają ceny (metody w jednym miejscu a nie porozwalane po xx klasach) to jeżeli są one poprawnie napisane i korzysta się tylko z nich do tego celu to nie ma żadnego kłopotu

Ale owszem jeżeli widzę kwiatki które przeliczają sumę koszyka w każdym jego kroku w całości i od nowa to już się mija kompletnie z celem.