Yep. Cents is the way to go. Then have "accounts" with limits set up, per row, so you won't encounter problems with large numbers. To elaborate on "limits", if a septillion dollars were to be stored in your database, but your database's data type is limited to supporting integers up to billions only, then you'll need to divide the septillion into billions.
It can be a little annoying and occasionally confusing always converting back and forth. You may also end up in a situation where you want to store a fraction of a cent which would be trivial with decimal/numeric but difficult with int
@@halftome Exactly, it also forces developers consuming the API to hopefully use ints in their code aswell, since transferring decimals via JSON would implicitly be interpreted as a float in most languages
@@lolxnn i’ll usually use a simple wrapper around serialising and deserialising the value, so my presentation layer can show it to the user in a less “confusing” way :) But otherwise, ints are the way to go
@@SamMeechWard every financial platform I've worked on has used minor unit amounts for anything outside of the presentation layer. It's by far the most common approach and really isn't that "annoying"
Bro from which videos you're making these shorts ?😅 they are interesting topics but can't seem to find full length videos on these. Is it purely a short clip or from a full topic video ?
Actually quite a lot of finance math is done with doubles, simply because performance is so much better. Is it inaccurate? Sure, but for many scenarios that is not a problem: Doubles have 18 significant figures. If all you need is two, three digits significance you can do quite a lot of math before the error adds up to become significant. It does mean you have to be quite careful about usage though.
@@Akroker1 The alternatives to doubles I had in mind would be some fixed point library or some decimal data type. Both options require some more complex operations for basic math. Also things like vectorization will be harder to do. If you're fine with just integer math it's probably a wash.
@@voodoo1094 I pretty consistently hear that the best way to store monetary values is an integer amounts of whatever the smallest division of currency is. So for US dollars, the monetary amount would just be the integer number of cents used. I suppose there could be some small situations where fractions of cents are relevant though, but probably not for 99% of use cases.
Hi, I'm Elon Musk, that is not enough, brother, there are people that have trillions, ok? Also, can you send me $100 on revolut to pay my Uber, I'm here with Joe Rogan and I forgot my phone at home. - Hi!(Joe Rogan)
Think of it like this, it’s impossible for you to represent 1/3 as finite decimal value, it’s just 0.33333 forever. If you wanted to add 1/3 to 1/3 in decimal, you would have to round the values and end up with something like 0.667 which is not equal to 2/3 Floats work in binary, so powers of 2 are fine, computers are good with 1/2 or 1/4 or 1/8 Something like 1/10 to us decimal thinkers is 0.1 but to a binary machine, it’s more like the 1/3 example, it can’t be represented as a finite number, so it gets rounded and you get an inaccurate decimal result
@@SamMeechWard Thank you for answer! That makes sense. Great explanation, like always. I guess you should always toFixed() the final return to the desired decimals, with floats. Anyway, keep up the good work!
You could store the values as cents instead of dollars allowing for integer math throughout your system.
Numeric does something like this under the hood
But sometimes the amount exceeds the integer's limit
Yep. Cents is the way to go. Then have "accounts" with limits set up, per row, so you won't encounter problems with large numbers.
To elaborate on "limits", if a septillion dollars were to be stored in your database, but your database's data type is limited to supporting integers up to billions only, then you'll need to divide the septillion into billions.
Thank you for these shorts, ive just started learning sql and these are really helpful!!!
Why not just storing the amount in cents using an int then format it as a currency only at the presentation level?
It can be a little annoying and occasionally confusing always converting back and forth.
You may also end up in a situation where you want to store a fraction of a cent which would be trivial with decimal/numeric but difficult with int
That’s exactly how Stripe does it, check out their API docs, it’s very well written!
@@halftome Exactly, it also forces developers consuming the API to hopefully use ints in their code aswell, since transferring decimals via JSON would implicitly be interpreted as a float in most languages
@@lolxnn i’ll usually use a simple wrapper around serialising and deserialising the value, so my presentation layer can show it to the user in a less “confusing” way :) But otherwise, ints are the way to go
@@SamMeechWard every financial platform I've worked on has used minor unit amounts for anything outside of the presentation layer. It's by far the most common approach and really isn't that "annoying"
Bro from which videos you're making these shorts ?😅 they are interesting topics but can't seem to find full length videos on these.
Is it purely a short clip or from a full topic video ?
idk if it's ur content or ur moustache, i always like ur videos before even watching them
The perfect loop
Actually quite a lot of finance math is done with doubles, simply because performance is so much better.
Is it inaccurate? Sure, but for many scenarios that is not a problem: Doubles have 18 significant figures. If all you need is two, three digits significance you can do quite a lot of math before the error adds up to become significant.
It does mean you have to be quite careful about usage though.
What operations are quicker with doubles than with integers?
@@Akroker1 The alternatives to doubles I had in mind would be some fixed point library or some decimal data type.
Both options require some more complex operations for basic math. Also things like vectorization will be harder to do.
If you're fine with just integer math it's probably a wash.
@@voodoo1094 I pretty consistently hear that the best way to store monetary values is an integer amounts of whatever the smallest division of currency is. So for US dollars, the monetary amount would just be the integer number of cents used. I suppose there could be some small situations where fractions of cents are relevant though, but probably not for 99% of use cases.
@@Akroker1 How would you convert between currencies then?
Devin knows that 😅
What is modeling tool you’re using?
How can one do that using drizzle?
What about mysql
Devin will replace you, how u feel about that?
Hi, I'm Elon Musk, that is not enough, brother, there are people that have trillions, ok? Also, can you send me $100 on revolut to pay my Uber, I'm here with Joe Rogan and I forgot my phone at home.
- Hi!(Joe Rogan)
Drug addict get out
Why are float not precise?
Think of it like this, it’s impossible for you to represent 1/3 as finite decimal value, it’s just 0.33333 forever. If you wanted to add 1/3 to 1/3 in decimal, you would have to round the values and end up with something like 0.667 which is not equal to 2/3
Floats work in binary, so powers of 2 are fine, computers are good with 1/2 or 1/4 or 1/8
Something like 1/10 to us decimal thinkers is 0.1 but to a binary machine, it’s more like the 1/3 example, it can’t be represented as a finite number, so it gets rounded and you get an inaccurate decimal result
@@SamMeechWard Thank you for answer! That makes sense. Great explanation, like always. I guess you should always toFixed() the final return to the desired decimals, with floats. Anyway, keep up the good work!