I've been using varchar(300),but I've also noticed longer urls.
views:
71answers:
3
+2
A:
Use TEXT, it's enough for every URL.
Note that with long URLs, you won't be able to create an index that covers the whole URL. If you need a UNIQUE index, you should calculate the URL hash, store the hash separately and index the hash instead.
Quassnoi
2010-02-03 12:25:58
Is it proper/standard way?
2010-02-03 12:27:40
What do you mean by "it"? `TEXT` is a standard and supported feature, `MD5` hashing is too (and `MySQL` contains a function for calculating the hash).
Quassnoi
2010-02-03 12:33:53
That's how I do it, as well. Also, it's worth considering benchmarking various hash functions, I chose MD5, since it's slightly faster than all the others, but MD4.
Nikola Kotur
2010-02-03 12:36:03
Seems there is no `MD4` in PHP.
2010-02-03 12:41:50
@Nikola: `MySQL` lacks `MD4` supports, but if it did, it would certainly be a preferred hash function.
Quassnoi
2010-02-03 12:43:33
Does this solution require a separate table to link hashes and urls ? These columns will obviously depend on each other.
eugene y
2010-02-03 12:50:47
@Quassnoi, yes, you're right, but I don't hash in MySQL (it showed slower), YMMV.@eugene y, hash is one of the columns in the table.
Nikola Kotur
2010-02-03 12:55:22
@unknown googler, yes it does, via Hash cryptography extension, do print_r(hash_algos()).
Nikola Kotur
2010-02-03 13:01:03
A:
As you can see here, browsers can handle different URL lengths (and very long). So you should consider using text as data type.
Felix Kling
2010-02-03 12:27:06