Hvilke type tåler , ?

[PS_CS4]

Hvilke type tåler komma?

 

Int fungerer ikke, kun varchar, som jeg har prøvd som fungerer(fungerer ikke ved pluss av f.eks 72.03 + 0.0005). Er det noen andre som fungerer?

[terjeelde]

Hvilke type tåler komma?

 

Int fungerer ikke, kun varchar, som jeg har prøvd som fungerer(fungerer ikke ved pluss av f.eks 72.03 + 0.0005). Er det noen andre som fungerer?

 

Jeg begynner som vanlig med å anbefale at du nevner hvilke databaseserver det er du bruker.

 

Er det en SQL server? MySQL? PostgreSQL? MS-SQL? Oracle?

 

Forskjellige servere støtter forskjellige data-typer.

 

For PostgreSQL f.eks:

 

Int == Integer == Heltall

Numeric == Variabelt antall siffer forran og bak komma

Real == Floating-point (flyttall, som er ting med komma. kan gi unøyaktigheter)

 

For penger er det ofte greit å bare lagre *100. Altså at du bare lagrer som øre, istedet for krone med desimal.

 

Viktig å huske å ikke bruke real/double/floating point til penger og andre ting hvor du vil ha ting nøyaktig.

[___]

Hvilke type tåler komma?

 

Int fungerer ikke, kun varchar, som jeg har prøvd som fungerer(fungerer ikke ved pluss av f.eks 72.03 + 0.0005). Er det noen andre som fungerer?

 

Tror du vi er tankelesere, eller tror du kanskje at det bare finnes en database?

 

Werner

[blackbrrd]

I postgresql fungerer det fint å bruke Numeric. Det var noen som testet ytelsen på numeric i forholdt til float/double, og ytelsesforskjellen var ikke noe å snakke om.

 

Jeg hadde ikke lagret penger som *100. Koden hvor du skal bruke dataene senere kommer til å bli rimelig surrete. Bruk f.eks Numeric(14,2), dvs 12 siffer foran komma og 2 etter komma. I java så kommer dette ut som BigDecimal.

[PS_CS4]

Jeg bruker MySQL.

[kaffenils]

Det som betyr noe er at du bruker riktige datatyper og at du parameteriserer (prepared statements) spørringene dine. Jeg gjetter på at du bygger opp spørringene dine ved konkatinere variabler, og at variablenes datatype er streng, ikke decimal/numeric eller hva det nå bør være.

[PS_CS4]

Det som betyr noe er at du bruker riktige datatyper og at du parameteriserer (prepared statements) spørringene dine. Jeg gjetter på at du bygger opp spørringene dine ved konkatinere variabler, og at variablenes datatype er streng, ikke decimal/numeric eller hva det nå bør være.

 

Gjør det slik:

 

	$ny_s = 0.0090;
$ny_rank = $rank + $ny_s;
mysql_query("UPDATE brukere SET rank = '$ny_rank' WHERE id = '" . $_SESSION['id'] . "'");

[kaffenils]

	$ny_s = 0.0090;
$ny_rank = $rank + $ny_s;
mysql_query("UPDATE brukere SET rank = '$ny_rank' WHERE id = '" . $_SESSION['id'] . "'");

Bruk prepared statements, alltid!

[PS_CS4]

	$ny_s = 0.0090;
 $ny_rank = $rank + $ny_s;
 mysql_query("UPDATE brukere SET rank = '$ny_rank' WHERE id = '" . $_SESSION['id'] . "'");

Bruk prepared statements, alltid!

 

 

 

Dette fungerer heller ikke da. (ikke sikker på om det er riktig )

Gi eksempel på det, i mitt tilfelle?

 

$ny_s = 0.040;
$ny_rank = $rank + $ny_s;
$dbh = execute("UPDATE brukere SET rank = '?' WHERE id = '" . $_SESSION['id'] . "'", $ny_rank);

[kaffenils]

Ikke putt ? i singlequotes (')

 

Basert på artikkelen vil jeg anta at det riktige blir noe slik. Hvis ikke dette fungerer så ville jeg spurt i PHP-forumet. Men be for guds skyld om hjelp til å bruke prepared statements!

/* Create a prepared statement */

if($stmt = $mysqli -> prepare("UPDATE brukere SET rank = WHERE id =?")) {

 

/* Bind parameters

s - string, b - boolean, i - int, etc */

$stmt -> bind_param("ds", $ny_rank , $_SESSION['id']);

 

/* Execute it */

$stmt -> execute();

 

/* Close statement */

$stmt -> close();

}

 

/* Close connection */

$mysqli -> close();

[terjeelde]

Jeg hadde ikke lagret penger som *100. Koden hvor du skal bruke dataene senere kommer til å bli rimelig surrete. Bruk f.eks Numeric(14,2), dvs 12 siffer foran komma og 2 etter komma. I java så kommer dette ut som BigDecimal.

 

For for å ikke lage misforståelser;

 

Numeric er absolutt ett bedre valg, ingen tvil om det, så lenge den (eller tilsvarende) er tilgjengelig. Viste ikke hvilke database han brukte, så nevnte for å være komplett.

 

Å lagre kroner*100 (øre) er absolutt ingen ideel løsning. Float er dog enda værre for å lagre penger, og det er ikke spesielt behagelig å lagre kroner og ører separat heller.

[blackbrrd]

Terjeelde:

 

Hvilke databaser er det idag som ikke støtter noe tilsvarende numeric? Det tror jeg ikke er mange. Ser ikke hvorfor man skal lagre beløpet som *100...

[terjeelde]

Hvilke databaser er det idag som ikke støtter noe tilsvarende numeric? Det tror jeg ikke er mange. Ser ikke hvorfor man skal lagre beløpet som *100...

 

Nå begynner vi vel å spore bra av fra topic, men siden du spør...

 

De fleste databaser vil jeg tro støtter noe ala numeric, men såvidt jeg vet gjør f.eks sqlite det ikke. Ettersom sqlite virker å være på topp 5-lista over hvilke databaser man gjerne får spørsmål om virket det verdt å nevne.

[siDDis]

Eg lagrer alltid penger i heltall, når det blir eindel av dei så kan man jo ikkje sløse cpu cycler på dyrebare flyttalskalkulasjoner.

[kaffenils]

Eg lagrer alltid penger i heltall, når det blir eindel av dei så kan man jo ikkje sløse cpu cycler på dyrebare flyttalskalkulasjoner.

Nå er det vel alt annet enn noen "simple" flyttallskalkulasjoner som bruker clock cycles når disse dataene behandles av et DBMS.

 

Sist jeg bekymret meg for clock cycles var da jeg drev med demoprogrammering i assembly på C64 i siste halvdel av 80-tallet

[blackbrrd]

Eg lagrer alltid penger i heltall, når det blir eindel av dei så kan man jo ikkje sløse cpu cycler på dyrebare flyttalskalkulasjoner.

Nå tenker jeg de på faktura sitter å banner.

 

Har vi solgt 10.000 av denne delen til 0,49kr til 0kr fordi en &%"##?28(+3 programmerer fant ut at tall etter komma bare var å sløse med cpu cycler?!?

 

Sjekket, og som du sier, sqlite støtter ikke numeric, kun flyt-tall. http://www.sqlite.org/datatype3.html

 

Avrundingsfeil i fakturering/regnskap er skikkelig populært.

[siDDis]

Eg har skreve eit program som rekne på RSI verdier for aksjekurser i realtime. Ytelesen er vanvittig mykje betre når eg rekne på talla som heiltall.

 

Å presentere dette er jo bare ein liten regex som setter . på rett plass.

[kaffenils]

Eg har skreve eit program som rekne på RSI verdier for aksjekurser i realtime. Ytelesen er vanvittig mykje betre når eg rekne på talla som heiltall.

Men nå snakker vi om kalkulasjoner på klientsiden. Dessuten er det forskjell på fixed point og floating point

 

Om du ber databasen summere verdiene i en floting point kolonne vs en heltallskolonne så tror jeg ikke du vil merke særlig forskjell da det er mye annet som vil eksekveres på serveren før summeringen kan begynne.

[blackbrrd]

Ikke så morsomt hvis du driver med mye ganging/deling, ettersom du da må holde rede på hvor mange desimaler du har...

 

Hvor gjorde du beregningene, databasen eller klienten?

Hvis databasen - hvilken database?

Hvis klienten - hvilket språk?

Endret 21. januar 2009 av blackbrrd

[siDDis]

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.