i agree with you that, in general, different contexts benefit from different representations of numbers. but it's also helpful for a system like a database to

i agree with you that, in general, different contexts benefit from different representations of numbers. but it's also helpful for a system like a database to come with reasonable defaults that give non-surprising behavior for common use cases. if databases are mostly going to be used for basic operational accounting and record keeping in businesses, for small data, where compute isn't a bottleneck, then making fixed point arithmetic that will give non-surprising results for typical businessy calculations seems like a good decision. it's great if the system offers opt-in ways for the discerning user to select the best numeric type for their application, but it's also great if users who don't read the manual get reasonable results for typical use cases. > I do like the idea of choosing what happens when integers overflow though it's entertaining to focus on what happens to the overall system surrounding the integer when answering 'what happens'. e.g. 'when the auto-incrementing integer used in the bowels of the internet banking customer session management system overflows during a holiday period, what happens is none of the bank's customers can log to access their money any more, so they become very angry, and then a bunch of staff get paged and spend days firefighting to bring the system back up' one can almost imagine a design meeting where the architect is outlining the various options for how the overall banking system will react when this particular integer overflow to a panel of business and technical stakeholders, and everyone voting for this choice.