Re: OT: Is MD5 ALWAYS 32 character long?

NO. An MD5 hash is 16 bytes - 128 bits no more - no less. It can be stored >not truncated< in a CHAR(16+) field or a VARCHAR(16+) field as binary data. As base 64 the same 128 bits occupies 22 bytes (yes that is CHAR(22) or VARCHAR(22)) and as hex it occupies 32 bytes, etc

Short answer yes

Longer answer VARCHAR slows indexing significantly. One varchar field means table is varchar. CHAR is space inefficient but much faster than varchar for select. AAYMMV

cheers

tachyon

Comment on Re: OT: Is MD5 ALWAYS 32 character long?

Replies are listed 'Best First'.
Re: Re: OT: Is MD5 ALWAYS 32 character long? by hardburn (Abbot) on Dec 18, 2003 at 16:26 UTC
CHAR is space inefficient but much faster than varchar for select. In this case, it's more space efficient, since you know that a MD5 string will always be a certain length l for a given encoding. The CHAR field will only need to store l characters, whereas VARCHAR will need to store l + the length of l. So I don't see any benefit to using VARCHAR in this case. Some databases may support bit vectors (like PostgreSQL's `BIT` type). In that case, you'll only need 16 bytes of storage space (assuming you use a non-`VARYING` bit field) compared to 32 bytes for hex encoding (assuming an 8-bit text encoding standard like ASCII (ok, technically 7-bit, but who actually stores it like that anymore?)). However, it's not portable to databases that don't support that type (like MySQL). ---- I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident. -- Schemer `: () { :\|:& };:` Note: All code is untested, unless otherwise stated	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re: Re: OT: Is MD5 ALWAYS 32 character long?
by hardburn (Abbot) on Dec 18, 2003 at 16:26 UTC

CHAR is space inefficient but much faster than varchar for select.

In this case, it's more space efficient, since you know that a MD5 string will always be a certain length l for a given encoding. The CHAR field will only need to store l characters, whereas VARCHAR will need to store l + the length of l. So I don't see any benefit to using VARCHAR in this case.

Some databases may support bit vectors (like PostgreSQL's BIT type). In that case, you'll only need 16 bytes of storage space (assuming you use a non-VARYING bit field) compared to 32 bytes for hex encoding (assuming an 8-bit text encoding standard like ASCII (ok, technically 7-bit, but who actually stores it like that anymore?)). However, it's not portable to databases that don't support that type (like MySQL).

----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

: () { :|:& };:

Note: All code is untested, unless otherwise stated

[reply]
[d/l]
[select]