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.
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.
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.
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 always use fixed point decimals for accounting. Floating points are approximations of decimals, which is the exact opposite what you want while accounting.
Useful for say, simulating aerodynamics or weather, not useful for precision tasks.
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.
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:
https://news.ycombinator.com/item?id=22155260
Just curious, because I don’t know, Postegres is all the rage, MySql is the og, where does Firebird carve its niche?
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.
> Postegres is all the rage, MySql is the og
From "influencers" i.e. YouTubers?
OG real world was Oracle and SQL Server.
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.
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.
Firebird is quite popular in russia. Relevant discussion here: https://forum.root.cz/index.php?topic=30553.msg421320#msg421...
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.
Do you encounter things where fixed point isn't good enough? (I.e. always store cents or millis etc?)
Or is the flexibility of not having to choose an advantage?
I always use fixed point decimals for accounting. Floating points are approximations of decimals, which is the exact opposite what you want while accounting.
Useful for say, simulating aerodynamics or weather, not useful for precision tasks.
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.
fair point, I forgot what a hog BigDecimal is...
Nice to see Firebird still being actively developed.