This is great news if you are coding accounting/banking software and good to see the IBM standards referenced. Given that decimal32 starts to see gaps in the continuous dollars.cents range at about $100,000 I don’t expect that has many real world applications (except legacy compatibility).
For general applications, I prefer to use Rational representation for decimals (Rat or FatRat) and Allomorphs (RatStr, FatRatStr) to maintain a literal representation like this https://raku.land/zef:librasteve/FatRatStr.
I'd also like to draw attention to the parent project Firebird. For some reason (probably its ties to Borland/Delphi?) it never became widely popular, even though it combines SQLite's ease of use with a proper fully featured database engine.
For example, it supports proper ALTER TABLE which doesn't force you to recreate tables and copy data around when you go beyond the most trivial use cases.
This is pretty much the only discussion I've found on this site:
These days, feature-wise, it's probably somewhere in the middle. It had support for things like window functions long before they became available in MySQL and friends.
What it gives you over both is single-file databases which are easy to share, and in-process embedded mode, just like SQLite.
Unlike SQLite, it doesn't only support embedded mode, but can also be turned into a "server" DBMS that supports remote access from multiple clients (like MySQL/PostgreSQL). Hundreds of concurrent connections work fine from what I've seen. This can be changed in either direction at your discretion, the database file remains the same.
My favorite anecdote relating to Firebird/Interbase (its original name) is that it is supposed to be renowned for its durability (i.e. resistance to corruption) and fast start times.
Because of this, they used it within the internal systems of the M-1 Abrahms tank.
Apparently when the main gun is fired, it gives off such a powerful energy impulse, that there is (at least was) a tendency for it to crash the internal systems.
So, they adopted Interbase because of its ability to work well in an environment where hard computer crashes are more a norm than an outlier.
Actually, considering its Ingres roots, I'd consider PostgreSQL OG as well. MS SQL Server on the other hand was just a port of Sybase (for OS/2) initially.
I don't get it. You had to face the problem of a type in a network protocol that had no direct Java equivalent, and decided, for something so low level and performance critical, to create a new instantiable Class? With the expressed intent to not use it for mathematical operations?
So instead of suffering the penalties of
bytes -> BigDecimal (with validation of course)
you thought it's better to add more construction steps in the form of
bytes -> Decimal32 (validation included) -> Big Decimal?
Do you know what kind of performance overhead this entails for your JDBC driver? Because the latter looks roughly about twice as slow, depending on the complexity of your validation code.
The type seems to just be a small wrapper around a BigDecimal; the actual conversion arithmetic will presumably be relatively extremely slow regardless, a single extra allocation (in addition to BigDecimal's ≥3) won't change much.
For general applications, I prefer to use Rational representation for decimals (Rat or FatRat) and Allomorphs (RatStr, FatRatStr) to maintain a literal representation like this https://raku.land/zef:librasteve/FatRatStr.
Or is the flexibility of not having to choose an advantage?
For example, it supports proper ALTER TABLE which doesn't force you to recreate tables and copy data around when you go beyond the most trivial use cases.
This is pretty much the only discussion I've found on this site:
https://news.ycombinator.com/item?id=22155260
What it gives you over both is single-file databases which are easy to share, and in-process embedded mode, just like SQLite.
Unlike SQLite, it doesn't only support embedded mode, but can also be turned into a "server" DBMS that supports remote access from multiple clients (like MySQL/PostgreSQL). Hundreds of concurrent connections work fine from what I've seen. This can be changed in either direction at your discretion, the database file remains the same.
Because of this, they used it within the internal systems of the M-1 Abrahms tank.
Apparently when the main gun is fired, it gives off such a powerful energy impulse, that there is (at least was) a tendency for it to crash the internal systems.
So, they adopted Interbase because of its ability to work well in an environment where hard computer crashes are more a norm than an outlier.
From "influencers" i.e. YouTubers?
OG real world was Oracle and SQL Server.
So instead of suffering the penalties of
bytes -> BigDecimal (with validation of course)
you thought it's better to add more construction steps in the form of
bytes -> Decimal32 (validation included) -> Big Decimal?
Do you know what kind of performance overhead this entails for your JDBC driver? Because the latter looks roughly about twice as slow, depending on the complexity of your validation code.