Artisanal Integers | Hacker News Reader

Artisanal Integers

neverendingbooks.org

49 pointserehweb31 comments

I have an artisanal integer. It's globally unique and leased to me by the phone company.

They even used to make a beautiful yearly book of artisanal integer owners where you could look up people's artisanal integers by name, but sadly that book is now out of print.

It's globally unique but if you stop paying a fee they are free to assign it to someone else!

I think we need an Artisanal Telephonic Integer Users' Bill of Rights to prevent this type of thing.

They even had a special typeface for that beautiful yearly book: https://en.wikipedia.org/wiki/Bell_Centennial

Off-topic (though hand-picked integers isn't much of a topic to begin with..) do you know of a font, preferably serif, that has the little cross bar on the digit 7 that's common to hand-writing but seems to be shunned by most font designers?

Bah, who wants these hipster "unique" integers? Real fashionistas want on-trend integers just like those used by famous celebrities! And what if I told you you there was a place you could get those for low low prices?... well, take a visit to http://canalstintegers.com

(Disclaimer: bad parody site from 2012 that I made very quickly, seems to still be working, but who knows.)

This is great!

    370372663736147970

    A dashing integer as used by TomCruise.com on Twitter.

Guaranteed Authentic™: http://twitter.com/TomCruise/status/370372663736147970

> Sorry, that page doesn’t exist!

That may be authentic but hardly original.

These were scrapped from top twitter celebrity tweets in 2012, I assume quite a few of them have may have deleted their old tweets since then.

Nobody got fired for picking 42.

Also see the Online Encyclopedia of Integer Sequences: https://oeis.org

You can download all of their integers for free. However all of them are already in use in mathematics. The smallest positive number not in use is 14972.

Are you telling me that 14972 is the smallest non-interesting number?

Well, not anymore. Everyone knows about it now!

FYI, this is the crux of an old "proof" that every number is interesting.

Well it's interesting to me. It is, apparently, not interesting to mathematicians.

It's pretty interesting to me. It reads like 1492 and 1972 at the same time.

> Because the long strings of alphanumerical characters and dashes provided by UUID are less efficient at the database layer, they needed Mission integers, or perhaps Brooklyn integers, or both.

What's the betting they a) never spent five minutes looking for an efficient way to store UUIDs in the database b) never profiled/benchmarked the performance c) never came within three orders of magnitude of the level of overall service performance where the difference would be noticeable?

I can't tell if it's satire or not, but its a fun concept

I thought UUIDs basically meant collisions would basically never happen though

> UUIDs

But they're not artisanal. We need lovingly hand-crafted integers to go along with our double-tall-half-caff-extra-hot-mocha-lattes, nautical tattoos and neck scarves /s

What other sort of scarves are there?

Hand scarves

That's called a towel.

Head scarves

That's called a shawl.

A shawl is worn over or around the shoulders. Sometimes that includes the head; sometimes is does not.

Try an image search. Or watch Fiddle on the Roof :) https://youtu.be/7V2lxFWBqfI?t=2m49s

In theory. Very much depends on implementation though.

Version 4 UUIDs largely depend on your RNG's quality to avoid collisions.

UUIDs are out because the article says they're inefficient to store in the database vs integers, so one hopes it is indeed satire.

UUIDs are less efficient in databases though, so that isn't complete bollocks.

* At 128 bits they are larger than the majority of integer types. If you are using them as keys for large data sets this might be a concern, especially if you are using them in a clustering key in SQL Server or similar because every non-clustered index entry would include the larger value too (a table with four extra indexes: that is 40 extra bytes per row if you have a UUID clustering key over a 64-bit integer, 60 extra compared to a 32 bit integer - if you have many millions or billions of rows that is worth considering).

* Unless using some tweak such as SQL Server's sequential UUIDs they result in significant fragmentation (assuming a b+tree index structure with allocation and cleanup semantics similar to SQL Server, other DBs may manage things differently) due to their effective randomness, which wastes storage space & memory and can therefore impose greater IO and RAM load beyond that implied by the difference in size.

UUIDs are great when you genuinely need them, but often an integer type is much more efficient so refrain from using them where you don't have a specific need to.

The article and the services described are definitely satire though.

  At 128 bits

And you'll probably end up handling them as 37-character strings, meaning you need 296 bits of space to store about 57 bits of data. And don't imagine you'll save any space by compressing it, as it's random and it'll compress terribly.

That depends on your DB (and DBAs/developers). A good database has a specific UUID type which stores the value as packed as it can be in 16 bytes.

Even without explicit support you could conceivably write a wrapper as part of your data access layer which packs them better (as 16 character strings assuming fixed 8-bits/character string types are truly 8-bit safe which is a fairly safe bet, or as a composite key of a number of integer columns).

Of course that doesn't stop people storing them as text instead anyway. Worse: I maintain a legacy system (with not time/budget to refactor and regression test something this fundamental) where many are stored as two-bytes-per-character text (SQL Server's nchar type) so that is 74 bytes (58 wasted per UUID column per row per table/index).

"Sequential" UUIDs like the special type implemented in MS SQL Server helps on the compression front (even when stored as proper binary types and not text) but it you are relying on compression for that you probably have other issues to deal with too...

"Because the long strings of alphanumerical characters and dashes provided by UUID are less efficient at the database layer"

If there is anyone reading this that is storing UUIDs as text, don't. They're 16 bytes, in hexadecimal with standardized hyphenation. Store 16 bytes. (Granted, that is still twice the storage of one of the offered integers,)

Reply on news.ycombinator.com