On 2021-09-29 10:21:00 -0600, Michael Lewis wrote:
> If your processes somehow allow updates on the wrong table, then fix that.
If your processes somehow allow inserting duplicate keys, then fix that
(so unique key constraints are unnecessary).
If your process somehow allows deletion of records which are still
referenced, then fix that (so foreign key constraints are unnecessary).
Many tools we use are defensive in nature. In a perfect world, they
would not be needed. However, users and programmers do make mistakes, so
we have tools (like constraints) to prevent those mistakes from
destroying data. The "don't reuse ids" trick is an additional tool to
catch mistakes. Not the most important (as I wrote I haven't used in
PostgreSQL before (although I've been using PostgreSQL for 7 years
now)), but it would have helped me catch a bug earlier last week which
is why I revisited it (Yes, I caught the bug during testing. But a bit
too close to going live for comfort.).
> If you run out of space in whatever value range you choose initially, the pain
> to upgrade to a type that allows larger values would seem to be very large.
I may have to do that before I retire (even without global ids). One of
my databases now has ids in the range of 500E6, and I guess it might
reach 2E9 over the next decade or so.
hp
--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@xxxxxx | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
Attachment:
signature.asc
Description: PGP signature
