6 ms·
> typical database column Typical for 70s and 80s. Honestly, designing a 21st century database is a different thing if compared to back then. You can use 128
by notorandit 1y ago
> typical database column
Typical for 70s and 80s.
Honestly, designing a 21st century database is a different thing if compared to back then.
You can use 128 bit integers, provided that you really want to use integers.
And maybe you put a timestamp along.
- j16sdiz 1y agolet's use 128bit integer and handle them like floats in php! and maybe put a 32bit timestamp along and pretend it can somehow store more than a 32bit integer can.
- jarofgreen 1y agoor use UUID/GUIDS, many databases (eg PostgreSQL) and frameworks (eg Django) support them.
- dwedge 1y agoUsing uuids can cause lots of problems with indexing, fragmentation, row size and index size
- throwawaysoxjje 1y agoNah I made the same mistake back in 2009 for a system that was storing behavior events during malware analysis. You don’t often expect to have two billion of something until you do.
- 9dev 1y agoIt's not like those two billion things just materialise in your database, right? Someone must have watched that graph climb, and climb, and climb, approaching the limit.
- detaro 1y agoIf they have that graph and remember the limit they choose 15 years ago... It's not something you think about constantly running a mostly stable code-wise site.
- shakna 1y agoSalesforce is a rather popular platform. Its defaults are also either a 18-character ID, or a 32bit integer. So, unless you take the effort to actually fight Apex, you're gonna hit this problem sooner or later.
- quickthrowman 1y agoDoesn’t an 18-character alphanumeric ID give you 18^36 combinations? 1.54 x 10^45 seems like enough combinations.
- shakna 1y agoThat's the point of the "or". You probably don't know which you're getting. It's what makes that particular design decision bite you more often.
- Sharlin 1y agoOne of the first things I internalized about databases was "just always use BIGSERIAL for primary keys". There are very few good reasons not to.
- deleted 1y ago[deleted]
- looperhacks 1y agoMaybe don't: https://wiki.postgresql.org/wiki/Don't_Do_This#Don.27t_use_serial https://wiki.postgresql.org/wiki/Don't_Do_This#Don.27t_use_s...
- rsynnott 1y agoThe website appears to date from 2008. This was a _very_ common latent bug at that point, particularly because Rails would basically force you to implement it. I assume this got fixed at some point, but for a long time all ActiveRecord models had an autoincrementing ID, which had to be a signed 32 bit int. There were scary monkey-patching workarounds if you wanted something more sensible. EDIT: And, yes, it is apparently Rails! https://fanlore.org/wiki/Archive_of_Our_Own#Timeline https://fanlore.org/wiki/Archive_of_Our_Own#Timeline