in reply to Storing uploaded files for speed and efficiency

Why don't you store things by date, then, if you don't need to be able to access these things later? If you need to have three characters, why not make them symbolic (A=January, B=February, C=March, etc;) So you could tack on the year, and you'd have a directory like /01G for July 2001.

If you have too many files per month, then you may want to switch to a new subdirectory per week or per day, i.e. /2001/jul/31/___.jpg or /01G/31/___.jpg ; The main reason behind this is too many subdirectories in a directory is just as bad as too many files.

The date-oriented approach is taken by a lot of websites - such as Webmonkey and Hotwired - even those that aren't database-oriented.

agermain
"In fact, we must do just the opposite and remain ever-vigilant, striving to ensure that we stop the Urkels of tomorrow before they gain power. Only by demanding full accountability can we reverse the shameful legacy of man's inanity to man."

  • Comment on Re: Storing uploaded files for speed and efficiency

Replies are listed 'Best First'.
Re: Re: Storing uploaded files for speed and efficiency
by legLess (Hermit) on Jul 31, 2001 at 19:47 UTC
    Thanks for the reply, Agermain. I don't think this solution would be as clean as ant's "a/an/ant", though. I don't have any way of predicting how much traffic this is goign to get, so maybe one directory a month is plenty, maybe one a day is better. I don't want to have to adjust the algorithm after the fact depending on traffic.

    I think your idea works better than my original one, though, since that would end up with 26^3 subdirectories! (doh)
    --
    man with no legs, inc.