Valuta-format

Hm, umiddelbart vil jeg tro, at grunden til at de skriver ,4 blot er for at kunne angive et givent beløb så præcists som muligt (fx DKK 123,1234).

I DK angiver beløb meget sjældent med over 2 decimaler, så 9,2 er vel fint som value til din datatype.

Mht til valg af datatype vil jeg anbefale FLOAT - den bruger mindst diskplads, men er desværre ikke helt så præcis som DOUBLE og DECIMAL. Hvis du blot skal plusse og minusse, så er FLOAT derfor helt klart det bedste valg.

Hej,

Okay, jeg prøvede nemlig at konvertere en Access-database til MySql via Migration Toolkit. I min Access havde jeg sat min kollonne til valuta til Dobbelt Reelt tal med 2 decimaler.

I den genererede MySQL blev kollonnen sat til datatypen DOUBLE(9,5) (?)
Men hvis Float er mere optimalt vil jeg da ændre det til det, jeg vil gerne kunne pludse og minusse. 

En anden ting:

Kollonner i den pågældende Access-database der var af typen "Autonummerering" er i MySql blevet sat til INT(10) - skal jeg her selv sætte dissse til "Autoincrement"?

DOUBLE vil virke helt fint - men den fylder bare mere end FLOAT. Som sagt hvis du KUN skal minusse og plusse er FLOAT optimalt. Hvis du skal lave mere avancerede matematisk operationer som fx at gange store beløb med andre store beløb, så er det måske en god idé at bruge DOUBLE.

Nu kender jeg ikke Migration Toolkit, men ja - du skal også selv sætte auto increment på de kolonner, der skal autonumereres i mysql.

Okay, det må jeg gøre så. Jeg skifter ud til float :-) Lige til sidst, er der en måde hvorpå man i MySQL administrator kan se en grafisk oversigt over ens tabeller og deres relationer?

Phpmyadmin! Det er en web-baseret service, der viser indholdet af din database. Det kræver PHP og kan hentes på phpmyadmin.net

Det kan dog være lidt tricky at installere første gang man gør.

Okay, det vil jeg lige se på :-)

Jeg takker mange gange for hjælpen. - Smid et svar!

Selv tak!

Man bør aldrig aldrig aldrig bruge float/double til beløb. Altid numeric/decimal.

Se f.eks. følgende eksempel - yderst logisk for enhver programmør, men vil give
et hjerteanfald hos enhver bogholder:

mysql> CREATE TABLE fproblem (id INT PRIMARY KEY,x FLOAT(12,2));
Query OK, 0 rows affected (0.02 sec)

mysql>
mysql> INSERT INTO fproblem VALUES (1, 1000000000);
Query OK, 1 row affected (0.00 sec)

mysql>
mysql> SELECT x FROM fproblem WHERE id=1;
+---------------+
| x            |
+---------------+
| 1000000000.00 |
+---------------+
1 row in set (0.00 sec)

mysql>
mysql> UPDATE fproblem SET x=x+1000 WHERE id=1;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql>
mysql> SELECT x FROM fproblem WHERE id=1;
+---------------+
| x            |
+---------------+
| 1000001024.00 |
+---------------+
1 row in set (0.00 sec)

mysql>
mysql> DROP TABLE fproblem;
Query OK, 0 rows affected (0.00 sec)

... har lige nærstuderet min gamle mysql-bog, og jeg må jo nok indrømme at arne har ret. Jeg beklager mit fejlagtige svar :( Hvis du skal bruge "store tal" så er decimal den sikre vej. Grunden til at din program anbefaler double som datatype er måske, at den bedømmer, at double er præcist nok til dine tal (double er mere præcist end float).

I øvrigt, det kan være arne kan forklare hvor mysql anbefaler 4 decimaler på "beløb-kolonner" (han pjejer at have svar på alt), eftersom mit svar (24/08-2006 14:36:05) er lidt tvivlsomt?

Hej igen,

Okay, vigtigt nok. Så det vil sige noget i retning af at float regner som om den havde med Bytes/MBytes at gøre?

Så decimal er den optimale løsning - men ja, forstår stadig heller ikke de 4 nuller, er det et spørgsmål om at få det så præcist som muligt, og så må man selv sørge for at formatere outputtet med 2 decimaler når det skal vises?

nej - de 1024 er et tilfaelde - det kunne lige saa godt have vaeret 993
eller 1009 - pointen er at FLOAT og DOUBLE har lidt usikkerhed - det er
helt fint til mange fysiske maal (det giver ikke mening at diskutere om
man har 15 km til arbejde eller 15.00001 km til arbejde), men til kroner og
oere kan det godt faa bogholdere og revisorer op af stolene

Der er en eller anden tradition for at bruge op til 4 decimaler paa beloeb.

Access currency understoetter ogsaa op til 4 decimaler.

Alle civiliserede lande bruger mig bekendt kun 2 decimaler.

Ah oky. - Vidste slet ikke at unøjagtigheder kunne forekomme på den måde. Så der er ingen far for at lave en DECIMAL(9,2) så længe det er DKK der regnes med. Men læg et svar også, så blev både razmuz_dk og jeg belært ud i talmagi :-)

svar

iøvrigt er 993 og 1009 ikke så sandsynelige som 1024 da det skal være en sum af
potenser af 2

+10000 giver 9984 (som er 8192 + 1024 + 512 + 256)

men på det overfladiske niveau så er der bare støj på de sidste decimaler

Okay. Jeg synes det er bemærkelsesværdigt nok at der i udviklingen er blevet tolereret de her unøjagtigheder og at de kan forekomme. - Men det er måske noget man har accepteret for at presse performance og space ned på et minimumsniveau? Jeg mener bare, man har da  altid været af den overbevisning at et apperat som en computer altid regner præcist ned til sidste decimal :-)

Mange har aldrig helt forstået floating point.

De har aldrig opført sig som fixed point og kommer heller aldrig til det.

Der er store fordele ved dem: de kan dække et utroligt stort range med en
relativ usikkerhed som er uafhængig af den absolutte værdi med data som
ikke fylder ret meget.

Og så er der nogen enkelte ulemper.

Et floating point tal kan dække så små tal som 10^-38 og så store tal som 10^38 i 4 byte.

En tilsvarende fixed point tal ville bruge ca. 32 bytes.

Og floating point er helt fine til afstande, vægt etc..

Men absolut ikke til beløb.

Fantastisk.. Jeg takker for hjælpen denne gang, og smider lige lidt ekstra points af. :-)

Hov lige en sidste, hvis nogen stadig hænger på.. Er DECIMAL at foretrække som datatype for valuta i alle de gængse databaser? (MsSQL, Access, Oracle osv.) ?

Ja.

(nogen database kalder faktisk typen for CURRENCY eller MONEY, men det er
samme concept)

Egenskaberne ved floating point er helt universielle og gaelder alle
CPU'er, styre systemer, programmerings sprog, databaser etc..

Okay fint. - Tak for det.