If I really wanted to compact my standard
yyyy-mm-dd file.avi notation / nomenclature, how might could I do it?
Well, naturally you can maybe toss the leading
20 in the year, and revert to a y2k type situation, but maybe that actually suits you.
Unfortunately, an id is not just a display filter, you really really want to be looking at the actual id in the id column, not some auto-smart-formatted shit, with who knows which locale.
Yet we can easily subset our view of the universe to just recent stuff (last 50 years) at which point it becomes moot. Even last 80 years, fine, still gives 20 years for projections. I know this may sound dumb (just write it out?) but let me just split a frog hair real quick, ok.
Naturally, the left side of the number shouldn’t change super rapidly, and the right side should tick up (just like an odometer..).
So we start with
yy and add month, day, maybe even time, and finally some serial suffix of adequate (?) length. There are only 12 months, but base 10 only 10 digits, so it’s a real bummer to use 2 characters on that, just as much as day.
It’s tempting to abbreviate months to single letters, but they wouldn’t sort naturally if you chose “logical” shorthands (j f m a y u l g s o n d). You could choose (a b c d e f g h i j k l) and hope people can count. It’s not that hard, but I’m not sure.
You could also just use base 12.. I think this is the simplest. X for ten, E for eleven, done. Zero would most naturally be December, which is weird knowing the latin root. But rolling around is truly zero, and December seems fitting. That last week of the year should be holiday, marked off the calendar (360 much nicer than 365/366!).
You can space out
yy-m-dd but why not just try for
It’s very convenient in english to say 3- or 4-digit numbers, like 495 or 316 or 2725, 4889, &c. It definitely gets a bit weird at 5 digits. You have to break it up weirdly (fucken primes). As long as you have fewer than 10,000 of a thing per day, you’re good to go. Past that, you just.. go to more suffixes.
So today’s stuff would be
High-volume transaction stuff might come back
20X15-0113-6001 up to 100 million.
If you use hex, which I’d be ok with (could also do months in hex, 1 .. 8 9 a b c), you lose the speakability but go up to 65k ids per quartet. That seems not worth it.
I’d almost say going A-Z would be fine, getting to 260,000 with just
20X15-A0123. It lends a certain symmetry that I like. A letter might be more useful as a prefix, for data-typing.
I guess I would store the whole thing as I guess fixed-length nchar(11) or what have you. Can alter column if we need to support longer ids. What’s nice about this is lack of the new suffix is fine, it just sorts fine.
Well, dates are not too hard to compact, especially if you can lose 2 digits on the year.
yyyy-mm-dd --> yyMdd ^--day of month ^--month, 1 2 3 4 5 6 7 8 9 X E 0 ^--year 20xx 2020-10-15 --> 20X15
I honestly don’t know of a single system I work with that would even want to reference something that old, even if it were to exist. Any ID worth using is worth reusing. If you’re never reusing IDs, I bet they’re unusable (at some point, unless they’re so new you can’t taste what’s to come). True, IPv4 and SSNs might be running out, but they’re vastly preferable to most anything else.
A single-letter prefix is good for something, like hungarian notation. Request 123 is not Report 123.
A20X15-1234 ^--serial number (runs out at 10,000) ^--day of month ^--month, 1 2 3 4 5 6 7 8 9 X E 0 ^--year 20xx (rolls over at 2100) ^--type/category
So you’d have stuff like A20X15-1238, C20X17-1022, R20X17-0023, nothing too unwieldy.