Well, it would be some sort of identifying ID again. Storing it as a BLOB really doesn't add anything more than storing the filename in the database, and then storing the file somewhere else.
If you can, store the file outside the site's document tree - somewhere else on the file system - and then the only way it can be accessed is via the database id/filename relation. If you can't, you might as well go the BLOB route, but that's the only reason it would be worthwhile.
Either way, you'd also want to shuffle id numbers and filenames - ruining any id-number/filename relationships built up. It won't affect any downloads in progress - the only race condition is the interval between someone receiving a chance to download file number 42, and actually starting the download - if number 42 gets reshuffled in between those two events, the user will get the wrong file.
The reshuffling could be table-wide on a regular basis, or randomly triggered on certain page accesses (because of the delay, put the shuffling code at the end of the page, after a flush() command, so that the user who triggered it doesn't have to sit around waiting); or it could be done on every access - whenever a file is requested, the script also picks two other files and swaps their ID numbers.
PS: Many Windows systems have a Scheduler thingy, which is a cron analogue.
