3 ms·
I would say the same kind of thing about primary keys on a database. If any imaginable sort of explosion in usage means INT could overflow in your lifetime, ju
by donatj 3y ago
I would say the same kind of thing about primary keys on a database.
If any imaginable sort of explosion in usage means INT could overflow in your lifetime, just go BIGINT.
I've had this burn be so many times. You don't want to be trying to retype a primary key and all the foreign keys that point to it frantically in the middle of the night ten years from now.
You're safeguarding your or your successors sleep.
- WJW 3y agoIs there ever a reason to use an INT these days? If you do have a lot of rows, you need BIGINT anyway. If you don't have a lot of rows, the few extra megabytes of disk usage from INT vs BIGINT are unlikely to cause any problems and are probably not even worth thinking about.
- donatj 3y agoA good example of where INT might make sense could be a table of a relatively set size, where other tables with massively more data had a foreign key to it. No chance of overflow, but as a BIGINT it would take a ton of space elsewhere. Even then though, it’s potentially not worth it.
- PaulHoule 3y agoI figure we might run out of UUIDs if we build a Dyson sphere.
- datadrivenangel 3y agoJust do IPv8
- Twirrim 3y agoJust this last Saturday before Christmas, an engineer I know at another company was frantically making schema changes to database schemas to shift from INT to BIGINT, after they hit the limit and everything started failing.