Gå til innhold

Anbefalte innlegg

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
Videoannonse
Annonse

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 av blackbrrd
Lenke til kommentar
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

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

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 konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...