Right now we multiply amounts by 100. It's already a problem since we need to multiply currency rates by at least 10,000. Also, it is difficult to maintain since you need to not forget to do multiplications each time.
Need to switch to using decimal.js and store raw decimal values in the DB as strings (or decimals, still TBD).
Pros:
– no need to care about multiply/divide logic, you can just work with raw values and return them to the client (so client will be simplified as well)
– DB will have readable values format
– if there's a need to add crypto support, or etc, it will require zero effort, but only updation to decimal.js config.
Cons:
– DB size will be increased compared to storing raw integers
– not able to make arithmetical operations directly in the SQL queries (currently we do that only in a single place)
– read/create/update operations in the DB require transformation from number to string and vice versa
TBD:
What data format return to client – number or string
What data format use to store in the DB – decimal number or string. Since we will still need to transform data in the DB => Model layer, there's no much difference in what format we need to store it. So in that case decimal might be better, since we will be able to make arithmetic operations with SQL queries in urgent cases (because we need to aim to make these calculations using JS in the services anyway).
Right now we multiply amounts by 100. It's already a problem since we need to multiply currency rates by at least 10,000. Also, it is difficult to maintain since you need to not forget to do multiplications each time.
Need to switch to using
decimal.js
and store raw decimal values in the DB as strings (or decimals, still TBD).Pros: – no need to care about multiply/divide logic, you can just work with raw values and return them to the client (so client will be simplified as well) – DB will have readable values format – if there's a need to add crypto support, or etc, it will require zero effort, but only updation to
decimal.js
config.Cons: – DB size will be increased compared to storing raw integers – not able to make arithmetical operations directly in the SQL queries (currently we do that only in a single place) – read/create/update operations in the DB require transformation from number to string and vice versa
TBD:
number
orstring
decimal number
orstring
. Since we will still need to transform data in theDB => Model
layer, there's no much difference in what format we need to store it. So in that casedecimal
might be better, since we will be able to make arithmetic operations with SQL queries in urgent cases (because we need to aim to make these calculations using JS in the services anyway).