[redenergy]

Tervist,
kuna sql tabelis INT ei saa salvestada komasid siis tuleks raha sisestada varchar?!
Aga kuidas kontrollida, et input oleks sisestatud ainult numbrid ja 1 koma/punkt?
Ja kui peaks arvutama SUM raha kokku kas siis koma ja punkt teevad sama välja?
Või peaks sentide puhul lubama ainult punkti kasutada?

[neros]

selleks on väljatüüp "DECIMAL". Seal on võimalik määrata maksimumpikkus enne- ja pärast koma.

[andrusny]

Sa peaks ennem salvestamist midagi sellist vast tegema.

[redenergy]

Suured tänud, sain kõik töötama nagu vaja.
Aga üks asi ei meeldi, nimelt Decimal 8,2 jätab kaks 0 taha isegi siis kui sente pole sisestatud.
näiteks 5.- teeb 5.00.-
Kas selle vastu ka rohtu on?

[mikk36]

redenergy, rohtu vast ei ole, kui soovid eemaldada, siis pead selle ise ära tundma.

[Fukiku]

Abiks ehk http://php.net/manual/en/function.number-format.php

[redenergy]

Kui keegi peaks sarnase asja vastu huvi tundma, siis toon endapoolse lahenduse mis leidsin.

[Fukiku]

Numbrite hoidmine baasis VARCHAR välja peal on iseenesest saatanast väga mitmetel põhjustel - alustades sellest, et sa ei garanteeri sellisel juhul 100% kindlusega, et sealt baasist alati number tuleb, kui sa seda ootad, kuni selleni, et sa ei saa näiteks teha päringuid stiilis "WHERE hind > 5".

Numbrite ilusaks vormistamiseks veebis näitamisel sobiksid ikkagi minu viidatud php funktsioon või mõni neist, millele viidatakse antud funktsiooni juurest "see also" alajaotuses.

[mikk36]

AB'st tuleb stringina tagasi väärtus? Saad ju teha tuima võrdluse

[redenergy]

Fukiku, olen jälle targem.
mikk36, suured tänud.

[mirko28]

Metoodiliselt on isegi parem kui proovid mitut lahendusviisi, sh ka lahendust, kus salvestad arve tekstina andmebaasi;)

[sosssepp]

Arve tekstina salvestades kulutad kettapinda juba palju rohkem, tõenäoliselt ka muid ressursse.

[blinx]

ma olen näinud et peale isnumeric kontrollitakse ka, et ei oleks tegu hex väärtusega
see on muidugi siis kui sa tahad, et su funktsioonid oleks hästi defineeritud ja suletud iga võimaliku argumentide kombinatsioonoi suhtes

[tola555]

mis andmebaasihaldamise süsteemiga tegu on? Osadel on raha jaoks spetsiaalsed tüübid nagu http://www.postgresql.org/docs/8.3/static/datatype-money.html , ka numeric on mõnes kohas olemas.

Vaata, et float ümardama ei hakkaks. Mina väldiks float-i ja double-it. Katseks võid sisestada 0.00000...001 või 0.99...99 ja pärast proovi sql-iga pärida, kas saad tagasi selle sama arvu.

[redenergy]

Kas money_format kasutades on võimalik EEK arvu taha tuua?
Või kas õigem ongi nii, et EEK 2.50 mitte 2.50 EEK?

[mikk36]

Pigem on abstraktne summa, ühiku võid ise eraldi tulpa panna.

[serk]

[2korda2]

Jäke palun meelde järgmised elementaarsed põhimõtted:
1. Rahaline summa/hind on alati number(x,y). Enamasti y=2. Erandid: ühikuhind (1 tiku hind), eelarve (üldjuhul kõik ümardatud täisarvuni või isegi tuhandete/miljoniteni, näiteks: "Käive: 1 700 tuhat krooni") jms
2. Hinnad ja summad joondatakse tulpades ALATI paremale.
3. Kui väärtuses, mida kuvatakse võivad olla ka komakohad, siis tuleb ALATI need kõik kuvada (vaata p1 formaati), sõltumata sellest kas seal on 00 või midagi muud. See on asi, millele ma olen siinsamas HV-s korduvalt tähelepanu juhtinud aga millegipärast pole ikka kohale jõudnud. Põhjus on elementaarne (leia loetelust suurim väärtus):
17.10
121
1100
130.20

4. Mitme valuuta puhul on universaalseim lahendus lisada eraldi valuuta veerg. Summasid seejuures oleks soovitav hoida mitmes veerus: summa näidatud valuutas, summa põhivaluutas. On loll idee hakata valuutakursse arvestama hetkel, kui raamatupidur vms teeb oma kuuaruannet. Eriti "kaval" arendaja liidab muidugi külma kõhuga kokku USD ja EUR summad.
5. Kui tegelete arvetega, siis jälgige, et ridade summa=päise summa. Ka võõrvaluutas. Märksõna: ümardusvahed.

Idee hakata arvulist väärtust varchar väljal hoidma väärib Darwini auhinda (läheb jagamisele koos ideega "hoiame arvet tekstilisena"). Tänu selliste mõttemeistrite lahendusele oli minu eelmise projekti migreerimise maht esialgse <500 tunni asemel lõpuks rohkem kui 1000 tunniga lõhki. Tõsi, seal oli lisaks eeltoodutele ka muid "häid" ideid:
1. kuupäev - varchar (kasutajal vabatekstiväli). Nüüd teisenda muuhulgas väärtused 05.06.07, 27.15.07, 21.jaan.1970, kolmapäev. Lahenduse juures arvesta, et kirjeid on miljonites.
2. Hulk väärtusi, mida tuleks eristada - teeme suure varchari, kasutajale vabatekstivälja ja las kasutajad ise otsustavad, mis nad eraldajana kasutavad (tädiautomaat on kõige süstemaatilisem andmesisestaja, eksole). Kirjed taas miljonites.
jne...

Andmemudel ei ole lihtsalt linnukese tegemise koht. Korralik andmemudel vähendab tunduvalt ohtu, et mõne aasta pärast tuleb uuele arendajale piinlikult selgitada oma varasemaid "leiutisi".

[Le Inc]

Mul Oracle 10g baasis sätitud koma kohaks "koma" (locale EST) ja php on koma kohaks "punkt" (pole saanud komaga tööle). Häda ka selles et 0,2323 arvude puhul Oracle ei anna "0", vaid trükib ,2323. Selleks tegin ühe funktsiooni, pole küll tugev käpp selles aga igatahes töötab (ta teeb "koma" ümber "punktiks" ka):

[mikk36]

Le Inc, selline funktsioon ei sobi?

[nemu]

[mikk36]

nemu, antud funktsiooni kasutamine seab piirangu ette komakohtade arvuga, mistõttu võib kohati kehv lahendus olla.

[nemu]

Kõige pealt tuleks oracle vastavad parameeterid kohendada:

[Le Inc]

[mikk36]

Mitte et ma mingi erilisem oleks, samuti hobikorras vaid.