Hash IDs (such as base64 YouTube video Ids): store as int/bigint, or as string, and why? I want to generate "unguessable" IDs, rather than /record/1, /record/2, /record/3 etc.

YouTube's style of using base 64 allows for 16.7 million IDs to be stored in just 4 characters (64 * 64 * 64 * 64).  This would be more than enough for my needs.

My only pondering is whether I should be storing them as ints in the database and converting them every time a request comes in (or when I need to generate a url), or storing them as the string that the user will see.  And why?

A couple of follow-up questions:

1) rather than generating random integers and converting them to the base64 string, should I use auto-increment numbers with a salt to randomise the alphabet, so I can get apparently "random" identifiers from IDs of 1 2 3 4 5 6 7 etc.  And why?

2) for table relationships should I use whatever I've generated as my PK/FK, or should that be a separate  column and just a simple auto-increment int, for some reason?
In SQL Server, I would store this as an int, and use CRYPT_GEN_RANDOM(4) to generate cryptographically random numbers for each row.  

Here's an example:

DECLARE @c int;
DECLARE @c_base64 varchar(8);
DECLARE @c_converted int;

--get the cryptographically random integer
SELECT @c = CONVERT(int, crypt_gen_random(4));
--convert it into a base-64 string
DECLARE @c int;
DECLARE @c_base64 varchar(8);
DECLARE @c_converted int;

--get the cryptographically random integer
SELECT @c = CONVERT(int, crypt_gen_random(4));
--convert it into a base-64 string
SELECT @c_base64 = (SELECT CONVERT(varbinary(4), @c) FOR XML PATH(''), BINARY BASE64);
--convert it back to an int
SELECT @c_converted = CONVERT(int, (CONVERT(xml, @c_base64).value('.', 'varbinary(4)')));
--display the original, the string, and the converted string
SELECT original = @c, converted = @c_base64, unconverted = @c_converted;


The results look like:

+-----------+-----------+-------------+
| original  | converted | unconverted |
+-----------+-----------+-------------+
| 629493479 | JYVO5w==  |   629493479 |
+-----------+-----------+-------------+

Why?  Storing integers will consume half the space of storing the converted string.  This may not seem like much on disk, but if you have a table with half a billion rows, every byte counts.  Wasting 2 bytes per row would mean you'd need an extra gigabyte of RAM to scan the table in that scenario.