Do I use varchar(36) or are there any better ways to do it?
I consider varchar's to be evil. If no data needs to be more than 256 characters, it is best to keep all data fixed-length. A fixed-length row makes getting to the ith element a simple multiply instead of iterating over and having to add the length of the current row to get to the next.
Jeff M
2009-01-05 05:53:16
Yup , totally right considering the fact the whole row should be in constant length.
Biswanath
2009-01-05 05:58:29
Woha! ever heard about indexes? no sane dbms does what you just said.
Sklivvz
2009-10-02 09:54:12
I do not have any information as how the database record are fetched. After reading Sklivvz comments I went digging on the net and found this http://dev.mysql.com/doc/refman/5.4/en/static-format.html, which is credible enough and in a way kind of supports Jeff M comment. But it is specific to MySql. Thanks,Biswanath.
Biswanath
2009-10-04 15:16:02
Varchar is evil, but looking at the huge limitations of MySql, using it would be the best maintenance/development choice
jalchr
2010-04-02 14:34:00
THe char size is fix, so it's better to use a char with fix size
marabol
2010-05-31 13:14:10
+6
A:
My DBA asked me when I asked about the best way to store GUIDs for my objects why I needed to store 16 bytes when I could do the same thing in 4 bytes with an Integer. Since he put that challenge out there to me I thought now was a good time to mention it. That being said...
You can store a guid as a CHAR(16) binary if you want to make the most optimal use of storage space.
thaBadDawg
2009-01-05 05:44:13
Because with 16 bytes, you can generate things in different databases, on different machines, at different times, and still merge the data together seamlessly :)
Billy ONeal
2010-09-02 00:12:08
+2
A:
char(36) would be a good choice. Also MySQL's UUID() function can be used which returns a 36-character text format (hex with hyphens) which can be used for retrievals of such IDs from the db.
Learning
2009-01-05 05:47:58
A:
I would hash it into a 8-byte integer and store the integer using a low-collision high-efficiency one-way hash algorithm like MurmurHash64A. This uses a lot less space and can be indexed and/or partitioned on. There is a SourceForge project that includes MemCached functions for mySQL (http://forge.mysql.com/projects/project.php?id=250) which might include MurmurHash64A, since Memchached uses it, but I don't know.
bretlowery
2010-06-07 20:52:31