Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.


Don'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.


A lot of times they are converted to BigInt and then stored as strings so different languages don't mess with the real value


Do 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.


No, 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.


This 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.


90% 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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: