Hoe sla ik het getal 8.000.000 op in MySql
Zoals het onderwerp aangeeft, wil ik graag bovenstaand getal opslaan in Mysql DB en het weergeven ervan.
Momenteel gebruik ik type BIGINT voor kolom met als default waarde 20 op.
Dit heb ik reeds opgezocht op het net en zou voldoende moeten zijn, maar telkens worden er een aantal nullen minder opgeslagen in DB. Ook het weergeven worden niet alle nullen weergeven.
Wat moet ik nog doen om dit in orde te maken/ te bewerkstelligen?
Dit zijn wel getallen:
8000000 (acht miljoen)
8000.000 (achtduizend , de laatste drie zijn decimalen)
Toevoeging op 18/09/2017 00:29:59:
een BIGINT slaat geen decimalen op en dus verlies je de nullen achter de decimale punt.
Gewijzigd op 18/09/2017 00:30:37 door Frank Nietbelangrijk
Wat Frank zegt ... opslaan zonder punten in het getal.
Bedankt voor jullie reacties.
Dus als ik het goed begrijp, kan ik het getal 8000000 opslaan en later weergeven als 8.000.000 met de functie number_format?
Ja, maar Mohamed, dit soort dingen *weet* je toch al? Hoe lang ben je ondertussen al bezig?
Eigenlijk is het niet vanzelfsprekend voor mij dat ik dit soort dingen zou moeten weten, aangezien mijn beroep niet een PHP-programmeur is, maar van origine een systeembeheerder. En, tegenwoordig door omstandigheden, ben ik meer bezig met coördineren, aansturen, plannen en wat daarbij hoort ;-)
Ik zou het daarom fijn vinden als er meer geduld en begrip voor me is. Tnx!
Oh jah door mijn zoektocht heb ik ontdekt: http://php.net/manual/en/function.money-format.php, want uiteindelijk wil ik geld opslaan en dan nl dollars en IQD.
En dus? Van origine ben ik ook systeembeheerder. Dat neemt niet weg dat je ook dan dit soort dingen weet. Systeembeheerders worden geacht databases in de vingers te hebben.
Het ligt eraan wie je werkgever is en wat die van je vraagt eigenlijk.
Of ben je zo een die geen formele opleiding heeft voor de systemen die hij beheert? Newsflash, dan ben je geen beheerder, dan ben je een stagiair.
Ieder bedrijf heeft databases draaien, groot en klein. Als beheerder ben je hier verantwoordelijk voor, samen met eventuele DBA's. Dat betekent dat je moet weten hoe de database omgaat met de machine waar hij op draait.
En dat alles doet niet teniet dat je ondertussen al TIJDEN in deze materie zit. Ondertussen moet je dan al wel een beetje weten waar je mee bezig bent. Ongeacht je originele beroep. Genoeg mensen hier die het programmeren alleen als hobby hebben, dus wat je originele beroep zegt er letterlijk niets over.
En zowel op MBO als op HBO heb ik colleges gehad over databases, maar eigenlijk was dat altijd heel basic. En als een systeembeheerder heb ik DB aangemaakt, verwijderd, logs ge-schrinked, SQL-servers geïnstalleerd, maar echt werken binnen een DB heb ik niet gedaan, want dit hoort niet tot de taken van een systeembeheerder ;-)
Als je een ander mening hebt over wel en wat niet een systeembeheerder moet kunnen, dan is dan helemaal geen probleem. We leven gelukkig in een land waar je je mening mag uiten ;-)
Maar eigenlijk ben ik hier niet voor discussies, maar als je dat wel wenst, dan ben ik er klaar voor ;-)
Voor hobbyprojecten is dat niet haalbaar, maar voor productiedoeleinden is dat hoe het hoort te gebeuren.
Uiteindelijk komt het op het volgende neer: ik zie topics van 9 maanden geleden van je voorbij komen. Als je in die tijd nog niet weet hoe je een getal in een database stopt heb je een erg lange weg te gaan voor je iets kan bouwen dat je online kan zetten. Ik hoop dan ook dat de applicatie waar je mee bezig bent puur een hobbyproject is, want de applicatie die ik in topics voorbij zie komen is kinderlijk eenvoudig open te breken. Met de komende wetgeving gaat dit iemand de kop kosten. Niet per definitie die van jou, maar je bent wel degene die dat veroorzaakt heeft in dat geval.
Gewijzigd op 19/09/2017 20:40:57 door Ben van Velzen
Eigenlijk zie je het verkeerd. Het gaat me niet zo zeer om een getal op te slaan in een DB, maar eerder het valuta 8.000.000 en het weergeven ervan. En jah, nu pas ben ik op dit punt gekomen, omdat ik eerder bezig was met andere punten/functies af te werken.
Ongetwijfeld, zal de applicatie kinderlijk eenvoudig open te breken, en daarom heb ik een lange weg te gaan om het te verbeteren, vind je niet ;-) En daarbij neem ik graag alle advies aan om de applicatie zo veilig mogelijk te maken. Al kun je dat niet 100% uitsluiten, maar je kunt de risico's wel verminderen.
BTW; wie zegt dat de applicatie in NL aangeboden/ mee gewerkt zal worden? En daarom is de wetgeving totaal niet van toepassing.
BTW; als je ziet hoeveel professionele apotheek applicaties in NL aangeboden worden, dan ben ik toch gek/niet realistisch om er eentje vanaf scratch te bouwen en wel door mezelf met weinig tot geen PHP-ervaring?
Zolang je hiermee bedoelt dat de DBA zich specialiseert in de inhoud, maar de systeembeheerder verantwoordelijk is en dus kennis heeft van wat er gebeurt dan zijn we het eens.
>> BTW; als je ziet hoeveel professionele apotheek applicaties in NL aangeboden worden, dan ben ik toch gek/niet realistisch om er eentje vanaf scratch te bouwen en wel door mezelf met weinig tot geen PHP-ervaring?
Ja, omdat ik weet waarom dat is. Er worden strenge eisen gesteld aan dit soort applicaties, met name de veiligheid hiervan. Kun je je het EPD nog herinneren? Daar hebben nogal wat hoofdjes op een zeer onaangename manier gerold.
>> BTW; wie zegt dat de applicatie in NL aangeboden/ mee gewerkt zal worden? En daarom is de wetgeving totaal niet van toepassing.
HA! Misschien verstandig om dat eens uit te zoeken. Als jij vanuit Nederland werkzaam bent dan val jij onder een combinatie van de Nederlandse wetgeving en die van het land waarin gewerkt gaat worden.
Gewijzigd op 19/09/2017 21:14:46 door Ben van Velzen
Ik vind en denk niet dat deze applicatie onder de Nederlandse wetgeving zal vallen, want de hostingserver staat fysiek niet in Nederland en daarnaast heeft Nederland/EU geen wetgeving/samenwerkingsverbanden in het land waar deze applicatie eventueel gebruikt zal worden ;-)
Nog meer redenen waar ik me eventueel zorgen om moet maken? Ik denk dat je heel strict kijkt en dat is jouw volledige recht, maar dat is hier niet van toepassing. Niet elk land heeft een strakke wetgeving als in Nederland en misschien is dat fout of goed voor dat ander land, maar dat doet er niet toe verder ;-)
>> Ik vind en denk niet dat deze applicatie onder de Nederlandse wetgeving zal vallen, want de hostingserver staat fysiek niet in Nederland en daarnaast heeft Nederland/EU geen wetgeving/samenwerkingsverbanden in het land waar deze applicatie eventueel gebruikt zal worden ;-)
Gelukkig maakt het niets uit wat jij vindt en denkt. Genoeg gevallen bekend waar men gewoon een zaak startte door naar het land van de programmeur af te reizen. Civiele procedures zijn door iedereen te starten, en een rechter gaat het niet leuk vinden als jij willens en wetens een slecht product levert. Dan heb je een schadevergoeding plus proceskosten te vergoeden. En nee, dan ben je niet klaar met 2 tientjes, ook niet met 200 tientjes.
Weet dondersgoed waar je aan begint, want als je dit niet voor een werkgever doet dan ben jij gewoon privé aansprakelijk mochten er gekke dingen gebeuren.
Gewijzigd op 19/09/2017 22:01:09 door Ben van Velzen
BIGINT = v/m -9223372036854775808 t/m 9223372036854775807
BIGINT UNSIGNED = v/m 0 t/m 18446744073709551615
En als je altijd rekent in centen heb je ook het probleem met scheidingstekens enzo niet. Bij het weergeven kun je (eind)bedragen altijd nog formatteren.
Correct. Ook kun je de padding (de 20 die je hebt) zo klein mogelijk maken. Dit kost je alleen maar verkeer tussen database en webserver.
Ben van Velzen op 19/09/2017 21:58:42:
Geen idee waar deze opmerking vandaan komt, want ik heb de applicatie zelf gemaakt, weliswaar met de hulp van anderen, maar het idee is duidelijk lijkt meDus je wil gaan verdienen over de rug van een ander? Ik hoop serieus dat dat goed gaat komen
"Ben:
Gelukkig maakt het niets uit wat jij vindt en denkt. Genoeg gevallen bekend waar men gewoon een zaak startte door naar het land van de programmeur af te reizen. Civiele procedures zijn door iedereen te starten, en een rechter gaat het niet leuk vinden als jij willens en wetens een slecht product levert. Dan heb je een schadevergoeding plus proceskosten te vergoeden. En nee, dan ben je niet klaar met 2 tientjes, ook niet met 200 tientjes.
Nogmaals je beredenering is gebaseerd op de NLse/Europese gedachtegang en dit op zich niets mee, maar zo werkt het niet in de rest van de wereld.
"Ben:
Zie mijn vorig antwoord ;-)Weet dondersgoed waar je aan begint, want als je dit niet voor een werkgever doet dan ben jij gewoon privé aansprakelijk mochten er gekke dingen gebeuren.
Welk deel van "Genoeg gevallen bekend waar men gewoon een zaak startte door naar het land van de programmeur af te reizen. Civiele procedures zijn door iedereen te starten, en een rechter gaat het niet leuk vinden als jij willens en wetens een slecht product levert. Dan heb je een schadevergoeding plus proceskosten te vergoeden. En nee, dan ben je niet klaar met 2 tientjes, ook niet met 200 tientjes." heb je nu niet begrepen? Dat heeft niets te maken met lokale wetgeving. Lees het voor de grap nog eens.
http://nen7510.knmp.nl/documenten/1211-1%20Beveiligingseisen%20elektronisch%20patientendossier%20aangepast%20voor%20apothekers.doc/at_download/file
Toch is het wel handig om te weten waarmee je begint met programmeren binnen de medische wereld waarbij vertrouwelijkheid, autorisatie en integriteit een belangrijk onderdeel vormen.
Gewijzigd op 20/09/2017 12:43:34 door - Ariën -