Well, if you read the storage type from the APM parameter, it will be a big mess. Changing the APM parameter will render all of your current files in CR unreadable. That is unless you put a trigger on the APM table that converts the storage mode of file-storage for all previously stored files when the APM parameter changes... and I really don't even want to entertain the idea of putting triggers all over the place (much less triggers on non-file-storage tables).
With the current approach, file-storage abstracts away from the storage type (i.e., you don't have to know what it is) for all operations except file creation. It uses Don's tcl routine cr_write_content to take care of actually retriving content (Don's routine is responsible for making the code so much cleaner). I think this is safer and "internally consistent". Even if you change the APM parameter midway, all of your files will still be readable even without explicit conversion of storage_type of previously stored files.
Perhaps what you could do is to have a proc that could be run when the server isn't busy, which will convert storage_type for all files in file-storage based on the current APM parameter. You need not change any existing file-storage code (because of the "internally-consistent" nature of how file-storage uses CR). This proc will be a nice addition to file-storage.
The other thing is that when you change storage type from database (the default) to filesystem, given that you already have some files on CR, it is true that some of your files will be in database and some in the filesystem. But is it really that critical? You have to backup both the filesystem and the database anyways when you use the filesystem. You could afford to "wait" for a more opportune time to do the storage_type conversion if you really want to have just one type of storage for all your file-storage files (or for performace reasons). Triggers are not necessary in this case, IMHO.
As for the file url, this is needed so that you have a nice default filename when you are actually downloading the file. Without the url, your default filename on downloads will be "index". I really haven't explored the performance issues, which you probably know more than me. But if indeed constructing the file url is the bottleneck and you don't seem to need it, removing it from the query should be ok.
