kaffenils Skrevet 21. januar 2009 Del Skrevet 21. januar 2009 Det blei gjort på klient siden med Python/scipy, sjølvsagt så er ikkje presisjon så viktig i denne beregninga som foregår på maks to desimaler. Tror heller at blackbrrd mener at hvis du f.eks. multipliserer 1000(=10 med to desimaler)*1000(=10 med to desimaler) så blir svaret 1000000(=100 med fire desimaler). Tilsvarende "problematisk" blir det med divisjon. Lenke til kommentar
blackbrrd Skrevet 21. januar 2009 Del Skrevet 21. januar 2009 (endret) Testet følgende på en tabell med 900000 rader: SELECT SUM(primarykey*(1.3::integer)) FROM tabell SELECT SUM(primarykey*(1.3::float)) FROM tabell SELECT SUM(primarykey*(1.3::numeric)) FROM tabell Spørringene tok i ms: integer = 156 float = 250 numeric = 478 SELECT count(primarykey) FROM tabell tok 109 ms Resultatet av float-numeric summene ble: -0.05078125 Dvs at mangelen på presisjon er rimelig merkbar ved bruk av float. Hvis man lar databasen gjøre kalkulasjonene så skal det mye gjøres at du vil bruke heltall istedetfor numeric... Jeg vet at Java sin BigDecimal klasse er vesentlig trengere enn i dette tilfellet, Postgresql sin implementasjon. Endret 21. januar 2009 av blackbrrd Lenke til kommentar
siDDis Skrevet 21. januar 2009 Del Skrevet 21. januar 2009 Det blei gjort på klient siden med Python/scipy, sjølvsagt så er ikkje presisjon så viktig i denne beregninga som foregår på maks to desimaler. Tror heller at blackbrrd mener at hvis du f.eks. multipliserer 1000(=10 med to desimaler)*1000(=10 med to desimaler) så blir svaret 1000000(=100 med fire desimaler). Tilsvarende "problematisk" blir det med divisjon. Det er jo ganske obligatorisk, altså det eg gjor var ikkje verre enn å jobbe med "ører" istadenfor "kroner". Skal ein ha mest mogleg ytelse for floating point kalkulasjoner så ville eg ha kikka på fortran eller blitz++. Heller gjøre det der enn rett i databasen om det er snakk om eindel større mengder data. Lenke til kommentar
blackbrrd Skrevet 21. januar 2009 Del Skrevet 21. januar 2009 For komplekse kalkulasjoner kan jeg forstå hvorfor man vil ha beregningene gjort på klienten istedetfor databaseserveren, men for relativt enkle beregninger må det da være mer effektivt å gjøre det i databasen? Nå kan det jo diskuteres hvor mye logikk som skal legges inn i databasen, men det er egentlig et annet spørsmål... Lenke til kommentar
siDDis Skrevet 21. januar 2009 Del Skrevet 21. januar 2009 Både og! Men for eksempelet mitt så hentes det data frå databasen og over http. Og svaret eg får trengs ikkje å lagres. Synes det er mykje meir behageleg å programmere i Python istadenfor PLSQL. Lenke til kommentar
Anbefalte innlegg
Opprett en konto eller logg inn for å kommentere
Du må være et medlem for å kunne skrive en kommentar
Opprett konto
Det er enkelt å melde seg inn for å starte en ny konto!
Start en kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå