Rendered at 04:02:59 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
homebrewer 16 hours ago [-]
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:
Just curious, because I don’t know, Postegres is all the rage, MySql is the og, where does Firebird carve its niche?
homebrewer 13 hours ago [-]
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.
whartung 12 hours ago [-]
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.
re-thc 12 hours ago [-]
> Postegres is all the rage, MySql is the og
From "influencers" i.e. YouTubers?
OG real world was Oracle and SQL Server.
steve1977 11 hours ago [-]
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.
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.
jmalicki 10 hours ago [-]
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?
exabrial 8 hours ago [-]
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.
rf15 12 hours ago [-]
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.
dzaima 11 hours ago [-]
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.
rf15 10 hours ago [-]
fair point, I forgot what a hog BigDecimal is...
sakesun 16 hours ago [-]
Nice to see Firebird still being actively developed.
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.
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?
Useful for say, simulating aerodynamics or weather, not useful for precision tasks.
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.