
Artisanal Integers - erehweb
http://www.neverendingbooks.org/artisanal-integers
======
pavlov
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.

~~~
madcaptenor
They even had a special typeface for that beautiful yearly book:
[https://en.wikipedia.org/wiki/Bell_Centennial](https://en.wikipedia.org/wiki/Bell_Centennial)

~~~
anon4
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?

------
mroth
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](http://canalstintegers.com)

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

~~~
binarymax
This is great!

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

Guaranteed Authentic™:
[http://twitter.com/TomCruise/status/370372663736147970](http://twitter.com/TomCruise/status/370372663736147970)

~~~
tempodox
> _Sorry, that page doesn’t exist!_

That may be authentic but hardly original.

~~~
mroth
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.

------
Houshalter
Also see the Online Encyclopedia of Integer Sequences:
[https://oeis.org](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.

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

~~~
KingMob
Well, not anymore. Everyone knows about it now!

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

------
lmm
> 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?

------
rtpg
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

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

~~~
dspillett
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.

~~~
michaelt

      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.

~~~
dspillett
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...

------
paulddraper
"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,)

