>> Wouldn't it make sense to convert the GUID to/from base64 so you get 6
>> bits per byte instead of 4 when using hex? That way your GUID's can be
>> char(22) instead of char(32) to hold 128 bits. It would save you ~1MB on
>> the database with 100,000 rows and more if you also have FK's.
>
> I jsut spent five years on a rapid response/support team. Text is
> readable with any tool, and the standard format is instantly identifiable.
> Base64 could be anything.
>
> At $1.00 per gigabyte at Office Depot, storage space is not worth as much
> as my time. If space was a consideration then I would agree, but 1MB is
> $0.001 worth of storage. It takes a lot of MB's to make up for the cost of
> my time.

I suppose so though base64 isn't anything odd or binary. You can easily
represent it with the characters A-Z, a-z, 0-9, and two other normal
characters so it is just regular text. Instead of packing 4 bits per byte
though you are getting 6 at no loss of being human readable and it might be
enough to make the difference in IO costs when you have a lot of records.

Seems to me to be a simple change that uses less space, might make selects
faster when you have tons of records, and doesn't lose you anything in human
readability!

--
Brad Pepers
brad@...