4 ms·
Personally the lack of a decimal type make SQLite a no-go for me. Its too much of a hassle to do financial operations completely on the application side.
by denismenace 11mo ago
Personally the lack of a decimal type make SQLite a no-go for me. Its too much of a hassle to do financial operations completely on the application side.
- burky 11mo agoThis and DATETIME. The workarounds for these are mostly fine if you’re just using SQLite as a key value store, but doing translations in SQL queries for these workarounds sounds atrocious.
- mike_d 11mo ago90% of people aren't using "SQL" anyway. They are just doing basic CRUD operations on a data store with SQL syntax, usually abstracted through an ORM. The only reason they want a SQL database in the first place is for ACID. If you find yourself caring about data types or actually writing a query, you should probably setup an actual database server.
- benjaminoakes 11mo agoDon't many financial transactions in US dollars get stored as integers anyway? The number of pennies, in other words. Then just convert to dollars with a decimal place when needing to display, etc. I recall this being pretty normal regardless of what database you use.
- fermuch 11mo agoA lot of times they are converted to BigInt and then stored as strings so different languages don't mess with the real value
- cweagans 11mo agoDo you only build stuff that performs financial operations? I'm not sure why sqlite being suboptimal for this one very specific use-case means that sqlite as a whole is a no-go for you.
- denismenace 11mo agoNo, not at all actually. But I had a lot of applications where at somepoint we needed to add storage of currency in the database. It became relevant for billing or other features. This without the app itself being financial in nature.