Discussion:
[MySQL] zaokraglanie SUM
(Wiadomość utworzona zbyt dawno temu. Odpowiedź niemożliwa.)
Krzysztof
2008-08-19 11:15:51 UTC
Permalink
Witam
Mam problem z zaokrąglaniem. Po przepuszczeniu przez funkcje SUM
pojawiają się dziwne rezultaty. Może ktoś już się spotkał z podobnym
problemem i pomoze.

Baza danych: MySQL 4.1, platforma Windows

Pola bazy danych do przechowywania wartości to float:
CREATE TABLE `fakturypozycje` (
(..)
`Cena_netto` float default NULL,
`Wartosc_netto` float default NULL,
`Wartosc_VAT` float default NULL,
`Wartosc_brutto` float default NULL,
(..)

Zawartość bazy danych:

SELECT
Wartosc_netto as SUM_Netto,
Wartosc_VAT as SUM_VAT,
Wartosc_brutto as SUM_Brutto,
Nazwa,
Symbol, procent
FROM fakturypozycje, stawkivat
WHERE Faktura_id=10 AND Stawka_VAT_ID=SYMBOL

SUM_Nettto: 148621
SUM_VAT: 32696,7
SUM_Brutto: 181318
Sa to wartosci poprawne.



Jak zapodaje grupowanie i sumowanie (jedna pozycja):

SELECT
SUM(Wartosc_netto) as SUM_Netto,
SUM(Wartosc_VAT) as SUM_VAT,
SUM(Wartosc_brutto) as SUM_Brutto,
Nazwa,
Symbol, procent
FROM fakturypozycje, stawkivat
WHERE Faktura_id=10 AND Stawka_VAT_ID=SYMBOL
GROUP BY Stawka_VAT_ID

SUM_Nettto: 148621,265625
SUM_VAT: 32696,6796875
SUM_Brutto: 181317,953125

Probowalem sztuczki z zaokraglaniem:
ROUND(SUM(Wartosc_netto),2) as SUM_Netto,
nie dziala poprawnie.
SUM_Nettto: 148621,27
SUM_VAT: 32696,68
SUM_Brutto: 181317,95

Dla mniejszych wartosci nie ma problemu.

Wydaje mi sie ze na serwerze nastepuje konwersja typu, dane sa
przechowywane w pamieci podrecznej jako double a zczytywane jako float.
Podobne jazdy były z typem currency w Delphi. Chodzilo o sposob
przechowywania wartosci w pamieci.

Bede jeszcze cwiczyl zmiane typu pol na double, zobaczymy co przyniesie.
Znalazlem cos takiego:
http://bugs.mysql.com/bug.php?id=25619
sugeruja uzycie round(x,2), ale jak widac - nie dziala to najlepiej



Pozdrawiam
Krzysztof Czajka
Troll
2008-08-19 12:52:49 UTC
Permalink
Post by Krzysztof
Witam
Mam problem z zaokrąglaniem. Po przepuszczeniu przez funkcje SUM
pojawiają się dziwne rezultaty. Może ktoś już się spotkał z podobnym
problemem i pomoze.
Baza danych: MySQL 4.1, platforma Windows
CREATE TABLE `fakturypozycje` (
(..)
`Cena_netto` float default NULL,
`Wartosc_netto` float default NULL,
`Wartosc_VAT` float default NULL,
`Wartosc_brutto` float default NULL,
(..)
naucz sie najpierw projektowac tabele, moim zdaniem ni epowinno byc wartosci
vat ani brutto tylko cena jednostkowa netto (lub brutto jak operujesz na
brutto)
id vatu i ilosc, reszta to pola wyliczeniowe..
Post by Krzysztof
ROUND(SUM(Wartosc_netto),2) as SUM_Netto,
a moze cast(wartosc_netto as numeric(15,2)) (lkub odpowiednik numeric jak
mysql nie ma


P.
--
http://wspolna-flaszka.pl - a Ty z kim dzisiaj pijesz? :-)
GrzesiekN
2008-08-19 20:21:58 UTC
Permalink
Ciekawe Troll w jaki sposób wyświetlisz zawartość tej tabeli z
policzoną kwotą VAT mając w definicji wiersza ID stawki VAT? Celowo
pewne rzeczy pozostawia się niezoptymalizowane aby ułatwić sobie
pobieranie danych. Dla Twojego pomysłu pozostaje podzapytanie
zagnieżdzone, a to pomysł skranie poroniony. Jedyne go Krzysztof
spartolił to fakt, że kolumny przechowujące kwoty domyślnie mają NULL,
powinno być 0, aby uniknąć problemów z funkcjami agregującymi.

Pozdrawiam. GrzesiekN
Troll
2008-08-20 07:29:41 UTC
Permalink
U?ytkownik "GrzesiekN" <***@gendo.pl> napisa? w wiadomo?ci news:b0306710-44b7-4608-aefc-***@y21g2000hsf.googlegroups.com...
"Ciekawe Troll w jaki sposób wyświetlisz zawartość tej tabeli z
policzoną kwotą VAT mając w definicji wiersza ID stawki VAT? Celowo
pewne rzeczy pozostawia się niezoptymalizowane aby ułatwić sobie
pobieranie danych. Dla Twojego pomysłu pozostaje podzapytanie
zagnieżdzone, a to pomysł skranie poroniony. ."

a to dlaczego podzapytanie skorelowane to pomysl skrajnie poroniony?


P.
GrzesiekN
2008-08-20 18:26:32 UTC
Permalink
Post by Troll
"Ciekawe Troll w jaki sposób wyświetlisz zawartość tej tabeli z
policzoną kwotą VAT mając w definicji wiersza ID stawki VAT? Celowo
pewne rzeczy pozostawia się niezoptymalizowane aby ułatwić sobie
pobieranie danych. Dla Twojego pomysłu pozostaje podzapytanie
zagnieżdzone, a to pomysł skranie poroniony. ."
a to dlaczego podzapytanie skorelowane to pomysl skrajnie poroniony?
P.
Samo zapytanie zagnieżdzone nie jest oczywiście żadnym problemem. Ale
skoro piszesz do kogoś "... naucz sie najpierw projektowac tabele" to
powinieneś na pierwszy rzut oka zauważyć, że przekazanie czegoś do
obliczeń przez ID do innej tabeli, a następnie zmiana wartości
powiązanej z tym ID spowoduje zmianę we wszystkich obliczanych polach
jakie przechowujesz w bazie ( w przypadku dokumentów VAT'u, brutto
itp. ma to akurat zasadnicze znaczenie ). No ale my nie potrafimy
projektować tabel tak jak Ty.

Pozdrawiam. GrzesiekN
Troll
2008-08-21 07:16:12 UTC
Permalink
Post by GrzesiekN
Samo zapytanie zagnieżdzone nie jest oczywiście żadnym problemem. Ale
skoro piszesz do kogoś "... naucz sie najpierw projektowac tabele" to
powinieneś na pierwszy rzut oka zauważyć, że przekazanie czegoś do
obliczeń przez ID do innej tabeli, a następnie zmiana wartości
powiązanej z tym ID spowoduje zmianę we wszystkich obliczanych polach
jakie przechowujesz w bazie
( w przypadku dokumentów VAT'u, brutto
itp. ma to akurat zasadnicze znaczenie ). No ale my nie potrafimy
projektować tabel tak jak Ty.
no przepraszam bardzo ale stawki vat nie zmianiasz z dnai na dzien. Sens
jest tylko w trzymaniu nazwy towaru , oraz danych z naglowka faktury gdyz
moze sie to przydac przy wystawianiu np noty korygujacej. Myslalem ze
znajdziesz jakis sensowny argument (w tym przypadku do obalenia) w rodzaju
szybkosci wykonanai zapytania, a ty z takim czyms wyjezdzasz..

P.
Andrzej
2008-08-21 08:38:20 UTC
Permalink
Post by Troll
no przepraszam bardzo ale stawki vat nie zmianiasz z dnai na dzien.
...ale jak już zmienią, to twój system staje, a inne dalej działają bez
zarzutu. Jest różnica?

pozdrófka...
Andrzej
Troll
2008-08-21 09:35:56 UTC
Permalink
Post by Andrzej
Post by Troll
no przepraszam bardzo ale stawki vat nie zmianiasz z dnai na dzien.
...ale jak już zmienią, to twój system staje, a inne dalej działają bez
zarzutu. Jest różnica?
no ale co zmienia stawke w slowniku z 22 na 7 ? a na jakiej podstawie i po
cholere? mozna dodac kolejna stawke, lub bez przeszkod zmienic w towarze na
inna. O czym my rozmawiamy, idac tym rozumowaniem w ogol eni epowinno sie
stosowac
normalizacji, przeciez ja nie pisze by trzymac id stawki w id towaru a id
towaru w szczergole faktury.

P.
Troll
2008-08-21 09:37:46 UTC
Permalink
Post by Andrzej
Post by Troll
no przepraszam bardzo ale stawki vat nie zmianiasz z dnai na dzien.
...ale jak już zmienią, to twój system staje, a inne dalej działają bez
zarzutu. Jest różnica?
i trzeba tak aplikacje robic by nie mozna bylo zmienic stawki dla ktorej sa
wystawione dokumenty ( w sensie samego slownika a nie stawki w towarze).A
jak sie nie bedzie dalo to system nie stanie.
wloochacz
2008-08-26 12:23:42 UTC
Permalink
Post by Troll
Post by Andrzej
Post by Troll
no przepraszam bardzo ale stawki vat nie zmianiasz z dnai na dzien.
...ale jak już zmienią, to twój system staje, a inne dalej działają bez
zarzutu. Jest różnica?
i trzeba tak aplikacje robic by nie mozna bylo zmienic stawki dla ktorej
sa wystawione dokumenty ( w sensie samego slownika a nie stawki w
towarze).A jak sie nie bedzie dalo to system nie stanie.
Bla, bla, bla...
Wiesz po co się NIE robi wartości wyliczanych?
Ano np. po to, żeby móc wyliczać cenę od brutto lub od netto.
Jak byś nie liczył i tak wyjdzie inaczej.
Masz dwa wyjścia - albo będziesz trzymał wartości wyliczone w bazie
(lekko, łatwo i przyjemnie), albo wyliczał dynamicznie, pamiętając o
kierunku wyliczania, zaokrągleniach dla drukarek fiskalnych i Bóg wie co
jeszcze.
Tak czy inaczej - rzeźba w gównie.
Projektowanie baz sobie, a praktyka sobie.
Poza tym denormalizacja bazy danych to wyższy poziomi od normalizacji,
także naucz się projektować bazy ;-)
--
wloochacz
Troll
2008-08-26 12:33:03 UTC
Permalink
Post by wloochacz
Post by Troll
Post by Andrzej
Post by Troll
no przepraszam bardzo ale stawki vat nie zmianiasz z dnai na dzien.
...ale jak już zmienią, to twój system staje, a inne dalej działają bez
zarzutu. Jest różnica?
i trzeba tak aplikacje robic by nie mozna bylo zmienic stawki dla ktorej
sa wystawione dokumenty ( w sensie samego slownika a nie stawki w
towarze).A jak sie nie bedzie dalo to system nie stanie.
Bla, bla, bla...
Wiesz po co się NIE robi wartości wyliczanych?
Ano np. po to, żeby móc wyliczać cenę od brutto lub od netto.
Jak byś nie liczył i tak wyjdzie inaczej.
jaki masz z tym problem? Chcesz wzor na wyliczenie netto od ceny brutto?
Po za tym skad zalozenie ze autor raz tak raz tak liczy z listy komumn jasno
wynika ze ma cene netto wartosc netto i wartosc brutto
nadal podtrzymuje ze to glupota.
Post by wloochacz
Masz dwa wyjścia - albo będziesz trzymał wartości wyliczone w bazie
(lekko, łatwo i przyjemnie), albo wyliczał dynamicznie, pamiętając o
kierunku wyliczania, zaokrągleniach dla drukarek fiskalnych i Bóg wie co
jeszcze.
i jaki masz z tym problem?
Post by wloochacz
Tak czy inaczej - rzeźba w gównie.
nie rzezba, wystarczy sobie raz przygotowac zapytanie liczace brutto (czy
netto od brutto) i wklejac.
Post by wloochacz
Projektowanie baz sobie, a praktyka sobie.
Poza tym denormalizacja bazy danych to wyższy poziomi od normalizacji,
także naucz się projektować bazy ;-)
bla bla bla :)

P.
wloochacz
2008-08-26 12:54:54 UTC
Permalink
Post by Troll
Post by wloochacz
Post by Troll
Post by Andrzej
Post by Troll
no przepraszam bardzo ale stawki vat nie zmianiasz z dnai na dzien.
...ale jak już zmienią, to twój system staje, a inne dalej działają bez
zarzutu. Jest różnica?
i trzeba tak aplikacje robic by nie mozna bylo zmienic stawki dla
ktorej sa wystawione dokumenty ( w sensie samego slownika a nie
stawki w towarze).A jak sie nie bedzie dalo to system nie stanie.
Bla, bla, bla...
Wiesz po co się NIE robi wartości wyliczanych?
Ano np. po to, żeby móc wyliczać cenę od brutto lub od netto.
Jak byś nie liczył i tak wyjdzie inaczej.
jaki masz z tym problem? Chcesz wzor na wyliczenie netto od ceny brutto?
Po za tym skad zalozenie ze autor raz tak raz tak liczy z listy komumn
jasno wynika ze ma cene netto wartosc netto i wartosc brutto
nadal podtrzymuje ze to glupota.
Chciałeś argumentów za, to dostałeś. Nie masz przeciw i twierdzisz, że
to głupota. Nawet wtedy gdy argument po łbie Cię wali.
Podtrzymuj sobie co tylko chcesz.
Nigdy nie słyszałeś prośby od klientów że czasem chcieliby wyliczać od
netto a czasem od brutto? Do tego dodaj sobie obsługę walut i komplet.
I to ma być uniwersalne?
Post by Troll
Post by wloochacz
Masz dwa wyjścia - albo będziesz trzymał wartości wyliczone w bazie
(lekko, łatwo i przyjemnie), albo wyliczał dynamicznie, pamiętając o
kierunku wyliczania, zaokrągleniach dla drukarek fiskalnych i Bóg wie
co jeszcze.
i jaki masz z tym problem?
Problem to ma klient, jak proste zestawienie sprzedaży mu się liczy
wieczność. No chyba że Twoje rozwiązania obsługują kilka FV na miesiąc -
to możesz naprawdę zrobić to koślawo - i tak będzie wystarczająco szybko.
Post by Troll
Post by wloochacz
Tak czy inaczej - rzeźba w gównie.
nie rzezba, wystarczy sobie raz przygotowac zapytanie liczace brutto
(czy netto od brutto) i wklejac.
Taa... jasne...
Ale użycie trwałych wartości będzie po prostu szybsze i prostsze.
Poza tym "wklejanie" to zafunduje Ci bardzo łatwy i przyjemny
refaktoring takiego kodu - powodzenia!
Post by Troll
Post by wloochacz
Projektowanie baz sobie, a praktyka sobie.
Poza tym denormalizacja bazy danych to wyższy poziomi od normalizacji,
także naucz się projektować bazy ;-)
bla bla bla :)
Widzisz; różnica jest taka, że ja swoje "bla" uzasadniłem, a Ty
zakończyłeś nim dyskusję. Jaki jest sens dyskutowania z Tobą?
--
wloochacz
Troll
2008-08-26 14:27:26 UTC
Permalink
Post by wloochacz
Nigdy nie słyszałeś prośby od klientów że czasem chcieliby wyliczać od
netto a czasem od brutto? Do tego dodaj sobie obsługę walut i komplet.
I to ma być uniwersalne?
mowimy o konkretnym przypadku. Zreszta nadal problemu nie widze, trzymasz
cene ilosc i wyliczasz albo z jednego wzoru albo z drugiego
Post by wloochacz
Post by Troll
i jaki masz z tym problem?
Problem to ma klient, jak proste zestawienie sprzedaży mu się liczy
wieczność. No chyba że Twoje rozwiązania obsługują kilka FV na miesiąc -
to możesz naprawdę zrobić to koślawo - i tak będzie wystarczająco szybko.
ze niby z jakiej racji proste dzialanie matematyczne ma sie wykonywac
wiecznosc? Mocno to naciagane.
Podaj przyklad gdzie mialo by to sie wyliczac wiecznosc. Wiecznosc to moze
trwac gdybym zastosowal podzapytanai skorelowane przy wybieraniu duuzej
liczby rekordow.
Post by wloochacz
Post by Troll
bla bla bla :)
Widzisz; różnica jest taka, że ja swoje "bla" uzasadniłem, a Ty
zakończyłeś nim dyskusję. Jaki jest sens dyskutowania z Tobą?
a daczego traktujez moje blablabla jakby odnosilo sie do calego posta ?

P.
wloochacz
2008-08-27 11:17:36 UTC
Permalink
Post by Troll
Post by wloochacz
Nigdy nie słyszałeś prośby od klientów że czasem chcieliby wyliczać od
netto a czasem od brutto? Do tego dodaj sobie obsługę walut i komplet.
I to ma być uniwersalne?
mowimy o konkretnym przypadku. Zreszta nadal problemu nie widze,
trzymasz cene ilosc i wyliczasz albo z jednego wzoru albo z drugiego
Nie. To Ty sobie ubzdurałeś, że mówimy o konkretnym przypadku próbując
uzasadnić swój pomysł, w momencie kiedy wskazuję Ci dlaczego takie
rozwiązanie może sprawiać kłopoty.
Nie zauważyłem, żebyś "mówił o konkretnym przypadku" kiedy proponowałeś
zastosować dynamiczne wyliczanie.
Post by Troll
Post by wloochacz
Post by Troll
i jaki masz z tym problem?
Problem to ma klient, jak proste zestawienie sprzedaży mu się liczy
wieczność. No chyba że Twoje rozwiązania obsługują kilka FV na miesiąc
- to możesz naprawdę zrobić to koślawo - i tak będzie wystarczająco
szybko.
ze niby z jakiej racji proste dzialanie matematyczne ma sie wykonywac
wiecznosc? Mocno to naciagane.
Podaj przyklad gdzie mialo by to sie wyliczac wiecznosc. Wiecznosc to
moze trwac gdybym zastosowal podzapytanai skorelowane przy wybieraniu
duuzej
liczby rekordow.
Podzapytania, procedurę lub cokolwiek co będzie wyliczać tę cenę.
Do tego każdy request o wartość musi wywołać kod. Każdy - i to jest
niepotrzebna komplikacja.
Do tego jakaś tam ilość rekordów i agregacja na polu "Wartość" - a to
jest możliwe wąskie gardło na własne życzenie.
Post by Troll
Post by wloochacz
Post by Troll
bla bla bla :)
Widzisz; różnica jest taka, że ja swoje "bla" uzasadniłem, a Ty
zakończyłeś nim dyskusję. Jaki jest sens dyskutowania z Tobą?
a daczego traktujez moje blablabla jakby odnosilo sie do calego posta ?
...
--
wloochacz
Troll
2008-08-27 12:03:15 UTC
Permalink
Post by wloochacz
Post by Troll
ze niby z jakiej racji proste dzialanie matematyczne ma sie wykonywac
wiecznosc? Mocno to naciagane.
Podaj przyklad gdzie mialo by to sie wyliczac wiecznosc. Wiecznosc to
moze trwac gdybym zastosowal podzapytanai skorelowane przy wybieraniu
duuzej
liczby rekordow.
Podzapytania, procedurę lub cokolwiek co będzie wyliczać tę cenę.
Do tego każdy request o wartość musi wywołać kod. Każdy - i to jest
niepotrzebna komplikacja.
nie mowimy o kompilkacji, kazde rozwiazanie wymaga jakiegos kodu, mowimy
teraz o szybkosci wyliczen
Post by wloochacz
Do tego jakaś tam ilość rekordów i agregacja na polu "Wartość" - a to jest
możliwe wąskie gardło na własne życzenie.
, prosze podac przyklad, ilosc rekordow itp,
zaraz sie przekoamy o jaki ulamek sekundy to dluzej trwa i zobaczymy czy
rzeczywiscie jest o co bic piane (z Twojej strony).


P.
wloochacz
2008-08-27 12:53:55 UTC
Permalink
Post by Troll
Post by wloochacz
Post by Troll
ze niby z jakiej racji proste dzialanie matematyczne ma sie wykonywac
wiecznosc? Mocno to naciagane.
Podaj przyklad gdzie mialo by to sie wyliczac wiecznosc. Wiecznosc to
moze trwac gdybym zastosowal podzapytanai skorelowane przy wybieraniu
duuzej
liczby rekordow.
Podzapytania, procedurę lub cokolwiek co będzie wyliczać tę cenę.
Do tego każdy request o wartość musi wywołać kod. Każdy - i to jest
niepotrzebna komplikacja.
nie mowimy o kompilkacji, kazde rozwiazanie wymaga jakiegos kodu, mowimy
teraz o szybkosci wyliczen
Jasne. I jak już to szybko się będzie liczyć, to nie będziesz chciał
sięgać do tej informacji z wielu różnych miejsc (app, procedury sql,
etc)? Daj spokój...
Post by Troll
Post by wloochacz
Do tego jakaś tam ilość rekordów i agregacja na polu "Wartość" - a to
jest możliwe wąskie gardło na własne życzenie.
, prosze podac przyklad, ilosc rekordow itp,
zaraz sie przekoamy o jaki ulamek sekundy to dluzej trwa i zobaczymy czy
rzeczywiscie jest o co bic piane (z Twojej strony).
Proszę się odczepić, panie Troll.
Nie mam ochoty Cię przekonywać (bo i po co? dla wątpliwej satysfakcji?),
imo wyliczanie w tym przypadku jest krzywe.
Rób jak uważasz, mnie nic do tego - na szczęście.

EOT
--
wloochacz
Troll
2008-08-27 15:44:51 UTC
Permalink
Post by wloochacz
Post by Troll
Post by wloochacz
Post by Troll
ze niby z jakiej racji proste dzialanie matematyczne ma sie wykonywac
wiecznosc? Mocno to naciagane.
Podaj przyklad gdzie mialo by to sie wyliczac wiecznosc. Wiecznosc to
moze trwac gdybym zastosowal podzapytanai skorelowane przy wybieraniu
duuzej
liczby rekordow.
Podzapytania, procedurę lub cokolwiek co będzie wyliczać tę cenę.
Do tego każdy request o wartość musi wywołać kod. Każdy - i to jest
niepotrzebna komplikacja.
nie mowimy o kompilkacji, kazde rozwiazanie wymaga jakiegos kodu, mowimy
teraz o szybkosci wyliczen
Jasne. I jak już to szybko się będzie liczyć, to nie będziesz chciał
sięgać do tej informacji z wielu różnych miejsc (app, procedury sql, etc)?
Daj spokój...
nie rozumiem o czym my rozmawiamy teraz, mowimy o bazie dla potrzeb danego
prograamu, juz sobie wyobrazam jak zwykly user siega po procedury
do bazy,z reszta mozna raz zrobic uniwersalna procedure i zniej korzystac,
to ty daj spokoj, na sile znow probujesz udowodnic ze nie mam racji, na
poczatku
zasugerowales ze przy liczeniu w te i we wte wynik jest inny, podaj
przyklad.
Post by wloochacz
Post by Troll
, prosze podac przyklad, ilosc rekordow itp,
zaraz sie przekoamy o jaki ulamek sekundy to dluzej trwa i zobaczymy czy
rzeczywiscie jest o co bic piane (z Twojej strony).
Proszę się odczepić, panie Troll.
Nie mam ochoty Cię przekonywać (bo i po co? dla wątpliwej satysfakcji?),
bo juz kilka razy sie madrzyles i okazalo sie ze blednie.
Post by wloochacz
imo wyliczanie w tym przypadku jest krzywe.
Rób jak uważasz, mnie nic do tego - na szczęście.
EOT
boimy sie ze nie mamy racji?

P.
wloochacz
2008-08-28 07:59:47 UTC
Permalink
Troll pisze:
[ciach]
Post by Troll
Post by wloochacz
Post by Troll
nie mowimy o kompilkacji, kazde rozwiazanie wymaga jakiegos kodu,
mowimy teraz o szybkosci wyliczen
Jasne. I jak już to szybko się będzie liczyć, to nie będziesz chciał
sięgać do tej informacji z wielu różnych miejsc (app, procedury sql,
etc)? Daj spokój...
nie rozumiem o czym my rozmawiamy teraz, mowimy o bazie dla potrzeb
To, że nie rozumiesz to mnie nie dziwi. Dziwi mnie natomiast to, że
nadal z Tobą pisze...
Post by Troll
danego prograamu, juz sobie wyobrazam jak zwykly user siega po procedury
do bazy,z reszta mozna raz zrobic uniwersalna procedure i zniej
korzystac, to ty daj spokoj, na sile znow probujesz udowodnic ze nie mam
racji, na poczatku
zasugerowales ze przy liczeniu w te i we wte wynik jest inny, podaj
przyklad.
Nie zasugerowałem, tylko stwierdziłem. Każde dziecko wie że tak jest.
Dlaczego ja mam udowadniać że koło nie jest kwadratowe?
Weź dowolną liczbę z 3/4 miejscami po przecinku jako cenę(dlaczego tyle?
zobacz z jaką dokładnością podawany jest kurs waluty), dość dużą ilość i
licz od netto i brutto. Dość szybko znajdziesz taką kombinację, która
nie daje takich samych wyników.

A w MySQL jest to niemal pewne.
Ta "baza danych" co prawda posiada typy o stałej precyzji (DECIMAL), ale
de-facto wartość przechowywana jest jako string, a obliczenia
wykonywane na decimal to tak naprawdę obliczenia zmiennoprzecinkowe.
Dopiero wersja 5.03 wprowadza normalność.
http://dev.mysql.com/doc/refman/4.1/en/problems-with-float.html

Podsumowując wady wyliczania dynamicznego:
1) Będą błędy w obliczeniach
2) Dodatkowy narzut na wyliczanie (kod, który wylicza)
Post by Troll
Post by wloochacz
Post by Troll
, prosze podac przyklad, ilosc rekordow itp,
zaraz sie przekoamy o jaki ulamek sekundy to dluzej trwa i zobaczymy
czy rzeczywiscie jest o co bic piane (z Twojej strony).
Proszę się odczepić, panie Troll.
Nie mam ochoty Cię przekonywać (bo i po co? dla wątpliwej satysfakcji?),
bo juz kilka razy sie madrzyles i okazalo sie ze blednie.
Oczywiście masz na to dowody?
A może znów chodzi Ci o ZEOS?
Post by Troll
Post by wloochacz
imo wyliczanie w tym przypadku jest krzywe.
Rób jak uważasz, mnie nic do tego - na szczęście.
EOT
boimy sie ze nie mamy racji?
Słuchaj - nawet gdybyś dostał racją między oczy i tak byś tego nie
zauważył. Mówiono ci to wiele razy przy wielu różnych okazjach.
--
wloochacz
Troll
2008-08-28 10:20:43 UTC
Permalink
Post by wloochacz
[ciach]
Post by Troll
Post by wloochacz
Post by Troll
nie mowimy o kompilkacji, kazde rozwiazanie wymaga jakiegos kodu,
mowimy teraz o szybkosci wyliczen
Jasne. I jak już to szybko się będzie liczyć, to nie będziesz chciał
sięgać do tej informacji z wielu różnych miejsc (app, procedury sql,
etc)? Daj spokój...
nie rozumiem o czym my rozmawiamy teraz, mowimy o bazie dla potrzeb
To, że nie rozumiesz to mnie nie dziwi. Dziwi mnie natomiast to, że nadal
z Tobą pisze...
bylo sie nie wtracac trolu
Post by wloochacz
Nie zasugerowałem, tylko stwierdziłem. Każde dziecko wie że tak jest.
Dlaczego ja mam udowadniać że koło nie jest kwadratowe?
Weź dowolną liczbę z 3/4 miejscami po przecinku jako cenę(dlaczego tyle?
zobacz z jaką dokładnością podawany jest kurs waluty), dość dużą ilość i
licz od netto i brutto. Dość szybko znajdziesz taką kombinację, która nie
daje takich samych wyników.
sygerujesz ze dwukrotnie da inna, inna przy zapisywaniu do bazy (bo tez
wyliczasz) i inna przy przy pozniejszym liczeniu ?
Czemu ja mam szukac kombinacji, postawiles teze to ja udowodnij, zapodaj
konkretny przyklad.
Post by wloochacz
A w MySQL jest to niemal pewne.
mam w dupie mysql. Dziwne ze nagle przestawiles sie na konkretny projekt
choc przed momentem wmawiales mi ze rozmwiamy ogolnie.
Jakos w postgresql nie mam tego typu problemow.
Post by wloochacz
Ta "baza danych" co prawda posiada typy o stałej precyzji (DECIMAL), ale
de-facto wartość przechowywana jest jako string, a obliczenia wykonywane
na decimal to tak naprawdę obliczenia zmiennoprzecinkowe. Dopiero wersja
5.03 wprowadza normalność.
http://dev.mysql.com/doc/refman/4.1/en/problems-with-float.html
to sie zdecyduj wkoncu, albo jest zle albo nie jest zle, wersja 4 to juz
historia
Post by wloochacz
1) Będą błędy w obliczeniach
jak ktos wzoru nie potrafi napisac to moze ma problem z poprawnym
wyliczeniem
Post by wloochacz
2) Dodatkowy narzut na wyliczanie (kod, który wylicza)
bez znaczenia przy dziesiejszych komputerach o ile dane nie sa pobierane z
innych tabel
Post by wloochacz
Post by Troll
bo juz kilka razy sie madrzyles i okazalo sie ze blednie.
Oczywiście masz na to dowody?
A może znów chodzi Ci o ZEOS?
bylo kilka przypadkow,nie bede sie powatrzal, masz w archiwum. (1. wplyw
componentu na triger - zarzucales mi ze sie nie znam jedno z drugim ni ema
nic wspolnego, pozniej sam problem na grupie zglosiles, 2. brak fizxycznego
zapisu danych w anydac - najpierw
zes pierdolil ze nie umiem poprawnie kodu zapisac co powoduje rzekomo ten
blad pozniej sie przyznales ze blad byl i zostal zgloszony),3 bylo cos
jesczsze nie chce mi sie szukac

generalnie zasada jest taka ze sie przyp. do mnie, choc nie zawsze masz co
madrego do powiedzenia.
Post by wloochacz
Post by Troll
boimy sie ze nie mamy racji?
Słuchaj - nawet gdybyś dostał racją między oczy i tak byś tego nie
zauważył. Mówiono ci to wiele razy przy wielu różnych okazjach.
jw.

P.
wloochacz
2008-08-28 10:58:36 UTC
Permalink
Troll pisze:
[ciach]
Post by Troll
Post by wloochacz
Post by Troll
nie rozumiem o czym my rozmawiamy teraz, mowimy o bazie dla potrzeb
To, że nie rozumiesz to mnie nie dziwi. Dziwi mnie natomiast to, że
nadal z Tobą pisze...
bylo sie nie wtracac trolu
Niestety nie mogę przejść obojętnie, jak ktoś pitoli trzy po trzy.
Tak jak ty, trollu.
Post by Troll
Post by wloochacz
Nie zasugerowałem, tylko stwierdziłem. Każde dziecko wie że tak jest.
Dlaczego ja mam udowadniać że koło nie jest kwadratowe?
Weź dowolną liczbę z 3/4 miejscami po przecinku jako cenę(dlaczego
tyle? zobacz z jaką dokładnością podawany jest kurs waluty), dość dużą
ilość i licz od netto i brutto. Dość szybko znajdziesz taką
kombinację, która nie daje takich samych wyników.
sygerujesz ze dwukrotnie da inna, inna przy zapisywaniu do bazy (bo tez
wyliczasz) i inna przy przy pozniejszym liczeniu ?
Nie da się otrzymać, przy pewnych wartościach, TAKIEJ SAMEJ wartości
ceny netto licznej od brutto i od netto.
(1,23[cena netto] + 22%[VAT]) x 32 685[ilość] = 49 047,1110
Dostajesz liczbę z większą precyzją niż PLN (zresztą cena brutto to już
1,5006).
Teraz chciałbyś otrzymać od podanej wartości brutto (49 047,11 ->
wartość po zaokrągleniach zgodnie z ustawą) odpowiednią cenę netto,
czyli DOKŁADNIE 1,23.
Jak ci się uda trollu, to daj znać.
Post by Troll
Czemu ja mam szukac kombinacji, postawiles teze to ja udowodnij, zapodaj
konkretny przyklad.
Post by wloochacz
A w MySQL jest to niemal pewne.
mam w dupie mysql. Dziwne ze nagle przestawiles sie na konkretny projekt
choc przed momentem wmawiales mi ze rozmwiamy ogolnie.
Wątek dotyczy konkretnej bazy danych.
A twoja "rada" jest zła, niezależnie od użytego silnika.
Można uzyskać w miarę dokładne wyniki, dobierając odpowiednie typy
danych (decimal) do obliczeń.
Post by Troll
Jakos w postgresql nie mam tego typu problemow.
Spójrz na subject, pacanie.
I nawet nie masz pojęcia dlaczego nie ma takich problemów w PGSQL.
A wiesz w ogóle co to jest liczba zmiennoprzecinkowa i operacje na niej?
Bo o cesze i mantysie to raczej na pewno nie słyszał - ke?
Post by Troll
Post by wloochacz
Ta "baza danych" co prawda posiada typy o stałej precyzji (DECIMAL),
ale de-facto wartość przechowywana jest jako string, a obliczenia
wykonywane na decimal to tak naprawdę obliczenia zmiennoprzecinkowe.
Dopiero wersja 5.03 wprowadza normalność.
http://dev.mysql.com/doc/refman/4.1/en/problems-with-float.html
to sie zdecyduj wkoncu, albo jest zle albo nie jest zle, wersja 4 to juz
historia
Posłuchaj ślepoto - pytacz jasno określił wersję której używa, cytuję
"MySQL 4.1, platforma Windows".
Post by Troll
Post by wloochacz
1) Będą błędy w obliczeniach
jak ktos wzoru nie potrafi napisac to moze ma problem z poprawnym
wyliczeniem
To jaki jest poprawny wzór?
Post by Troll
Post by wloochacz
2) Dodatkowy narzut na wyliczanie (kod, który wylicza)
bez znaczenia przy dziesiejszych komputerach o ile dane nie sa pobierane
z innych tabel
Oczywiście.
Post by Troll
Post by wloochacz
Post by Troll
bo juz kilka razy sie madrzyles i okazalo sie ze blednie.
Oczywiście masz na to dowody?
A może znów chodzi Ci o ZEOS?
bylo kilka przypadkow,nie bede sie powatrzal, masz w archiwum. (1. wplyw
componentu na triger - zarzucales mi ze sie nie znam jedno z drugim ni
ema nic wspolnego, pozniej sam problem na grupie zglosiles,
Zgadza się; Dymitry radośnie ustawiał odpowiednią flagę. Problem
dotyczył tylko i wyłącznie MS SQL.

2. brak
Post by Troll
fizxycznego zapisu danych w anydac - najpierw
zes pierdolil ze nie umiem poprawnie kodu zapisac co powoduje rzekomo
ten blad pozniej sie przyznales ze blad byl i zostal zgloszony),
Nie przypominam sobie.
Za to przypominam sobie, że nie potrafisz napisać poprawnego kodu.

3 bylo
Post by Troll
cos jesczsze nie chce mi sie szukac
Dziury w pamięci? Problemy z kojarzeniem?
Zgłoś się do odpowiedniej poradni, trollu.
Post by Troll
generalnie zasada jest taka ze sie przyp. do mnie, choc nie zawsze masz
co madrego do powiedzenia.
Oczywiście. Będę cię tępił ilekroć wynurzysz swój brudny pysk i
zaczniesz kłapać idiotyzmy.
Post by Troll
Post by wloochacz
Post by Troll
boimy sie ze nie mamy racji?
Słuchaj - nawet gdybyś dostał racją między oczy i tak byś tego nie
zauważył. Mówiono ci to wiele razy przy wielu różnych okazjach.
jw.
--
wloochacz
Krzysztof
2008-08-20 08:00:28 UTC
Permalink
Post by Troll
Post by Krzysztof
Witam
Mam problem z zaokrąglaniem. Po przepuszczeniu przez funkcje SUM
pojawiają się dziwne rezultaty. Może ktoś już się spotkał z podobnym
problemem i pomoze.
Baza danych: MySQL 4.1, platforma Windows
CREATE TABLE `fakturypozycje` (
(..)
`Cena_netto` float default NULL,
`Wartosc_netto` float default NULL,
`Wartosc_VAT` float default NULL,
`Wartosc_brutto` float default NULL,
(..)
naucz sie najpierw projektowac tabele, moim zdaniem ni epowinno byc
wartosci vat ani brutto tylko cena jednostkowa netto (lub brutto jak
operujesz na brutto)
id vatu i ilosc, reszta to pola wyliczeniowe..
:) Projekt jest dostosowany do potrzeb klienta. Dane sa zasysane z
innego programu i muszą być identyczne - nie we wszystkich przypadkach
pole VAT jest wyliczane (dokumenty SAD).
Post by Troll
Post by Krzysztof
ROUND(SUM(Wartosc_netto),2) as SUM_Netto,
a moze cast(wartosc_netto as numeric(15,2)) (lkub odpowiednik numeric
jak mysql nie ma
A dziekuje bardzo za podpowiedz. Sprobuje.

Swoja droga znalazlem:
http://dev.mysql.com/doc/refman/5.0/en/numeric-type-overview.html
"Using FLOAT might give you some unexpected problems because all
calculations in MySQL are done with double precision."

http://dev.mysql.com/doc/refman/5.0/en/no-matching-rows.html
"If you are comparing FLOAT or DOUBLE columns with numbers that have
decimals, you can't use equality (=) comparisons. This problem is common
in most computer languages because not all floating-point values can be
stored with exact precision."

Czyli wniosek jest prosty - nie uzywac float jezeli w przyszlosci
bedziemy przeprowadzac jakiekolwiek operacje na tym polu.

Pozdrawiam
Krzysztof Czajka
Krzysztof
2008-08-20 14:02:44 UTC
Permalink
Post by Troll
Post by Krzysztof
Witam
Mam problem z zaokrąglaniem. Po przepuszczeniu przez funkcje SUM
pojawiają się dziwne rezultaty. Może ktoś już się spotkał z podobnym
problemem i pomoze.
a moze cast(wartosc_netto as numeric(15,2)) (lkub odpowiednik numeric
jak mysql nie ma
Zadzialalo rzutowanie z float na char a nastepnie (wewnatrz mysql) na
double:

SUM(CAST(Wartosc_netto as CHAR))

yhm... bardzo optymalnie z cyklu jak nie nalezy tego robic ;)
Majac ten slad dokonalem konwersji pola tabeli float najpierw na varchar
a nastepnie na double.

Dziekuje za pomysl rzutowania typow.

Pozdrawiam
Krzysztof Czajka
n0-eXit
2008-08-27 11:54:56 UTC
Permalink
sprobuj moze przejsc na DOUBLE, float to liczby o pojedynczej precyzji
i jako takie moga byc zrodlem tych dziwnych zaokraglen.
Krzysztof
2008-08-28 07:08:21 UTC
Permalink
Post by n0-eXit
sprobuj moze przejsc na DOUBLE, float to liczby o pojedynczej precyzji
i jako takie moga byc zrodlem tych dziwnych zaokraglen.
Dzięki, już do tego doszedłem :)
Zastosowanie float zamiast double było przyczyną kłopotów.
Message-ID: <g8h3v2$iba$***@node1.news.atman.pl>
Date: 2008-08-20 16:02


Pozdrawiam
Krzysztof Czajka
wloochacz
2008-08-28 08:00:37 UTC
Permalink
Post by Krzysztof
Post by n0-eXit
sprobuj moze przejsc na DOUBLE, float to liczby o pojedynczej precyzji
i jako takie moga byc zrodlem tych dziwnych zaokraglen.
Dzięki, już do tego doszedłem :)
Zastosowanie float zamiast double było przyczyną kłopotów.
To nie jest rozwiązanie, tylko obejście problemu, które może się zemścić.
http://dev.mysql.com/doc/refman/4.1/en/problems-with-float.html
--
wloochacz
Krzysztof
2008-08-28 09:08:10 UTC
Permalink
Post by wloochacz
Post by Krzysztof
Post by n0-eXit
sprobuj moze przejsc na DOUBLE, float to liczby o pojedynczej precyzji
i jako takie moga byc zrodlem tych dziwnych zaokraglen.
Dzięki, już do tego doszedłem :)
Zastosowanie float zamiast double było przyczyną kłopotów.
To nie jest rozwiązanie, tylko obejście problemu, które może się zemścić.
http://dev.mysql.com/doc/refman/4.1/en/problems-with-float.html
Ekhm... chyba źle napisałem albo źle mnie zrozumiano.
Przyczyna kłopotów = float. Usunięcie kłopotów = używanie typu double w
_tabeli_ .
Zresztą macie to powyżej... [widocznie KF wam wyciął ;p ]
http://tinyurl.com/5abswo


Pozdrawiam
Krzysztof Czajka
Tygrys
2008-08-28 10:54:53 UTC
Permalink
Post by Krzysztof
Ekhm... chyba źle napisałem albo źle mnie zrozumiano.
Przyczyna kłopotów = float. Usunięcie kłopotów = używanie typu double w
_tabeli_ .
Użycie typu Double zamiast float to nie usunięcie a przesunięcie
kłopotów trochę dalej, co nie znaczy że całkiem znikają. Przez to potem
jest je jeszcze trudniej wykryć.

Przyczyną kłopotów jest używanie arytmetyki zmiennopozycyjnej (float,
double, real) dla DOKŁADNYCH obliczeń.

Prostym przykładem jest jest w systemie dziesiętnym (1/3 * 3) - 1 = 0.
dla float to wygląda jak (0,3333333 * 3) - 1 = -0,0000001
dla double jest (0,33333333333333333 * 3) - 1 = -0,00000000000000001

Czyli dalej źle, ale błąd jakoby mniejszy.
Dla rozwinięć binarnych jest podobnie.

Po prostu nie każdą liczbę da się dokładnie zapisać w systemie dwójkowym
przy skończonej precyzji (miejscach znaczących).

Tygrys

Loading...