On Sat, 2009-07-11 at 00:01 +0000, oooooooooooo ooooooooooooo wrote:
You mentioned that the data can be retrieved from somewhere else. Is some part of this filename a unique key?
The real key is up to 1023 chracters long and it's unique, but I have to trim to 256 charactes, by this way is not unique unless I add the hash.
Do you have to track this relationship anyway - or age/expire content?
I have to track the long filename -> short file name realation ship. Age is not relevant here.
I'd try to arrange things
so the most likely scenario would take the fewest operations. Perhaps a mix of hash+filename would give direct access 99+% of the time and you could move all copies of collisions to a different area.
yes its a good idea, but at this point I don't want to add more complexity tomy app, and having a separate area for collisions would make it more complex.
Then you could keep the database mapping the full name to the hashed path but you'd only have to consult it when the open() attempt fails.
As the long filename is up to 1023 chars long i can't index it with mysql (it has a lower max limit). That's why I use the hash which is indexed). What I do is keeping a list of just the md5 of teh cached files in memory in my app, before going to mysql, I frist check if it's in the list (realy a RB-Tree).
--- It is 1024 chars long. Witch want still help. MSSQL 2005 and up is longer, if your interested: http://msdn.microsoft.com/en-us/library/ms143432.aspx But that greatly depends on your data size 900 bytes is the limit but can be exceeded.
You can use either one if you do a unique key id name for the index. File name to Unique short name. I would not store images in either one as your SELECT LIKE and Random will kill it. As much as I like DBs I have to say the flat file system is for those.
John